Re:Git Rebase for the Terrified
by rpcope1 on Tuesday January 13, 2026 @12:08PM
(#46603974)
I have worked on several codebases where it was enforced that the commit be rebased off of whatever the main branch was, all units of work squashed to a single commit, and only "working" code be checked into the main branch. This gives you a really good linear history, and when you're disciplined about writing good final commit messages and tagging them to a ticket, it means bisecting to find challenging bugs later becomes tractable, as each commit nominally should work and should be ready to deploy for testing. I've personally solved a number of challenging regressions this way.
[ Parent
| on HN ]
>each commit nominally should work
Except it can be the result of 10 squashed commits.
Re:Git Rebase for the Terrified
by bastardoperator on Tuesday January 13, 2026 @03:12PM
(#46607195)
Which is the entire point of it. Why should I look at ten commits when I can look at one and get the same exact data? Why should I pollute my production history for what a is likely a bunch of debugging commits? The branch is a scratchpad, you should feel empowered within your own branch, rebase allows you to be lazy in the development cycle while presenting a nice clean set of changes at the end of it.
You can split your work in multiple commits and at the same time drop/squash debugging or wip changes. The result allows you to go into much better detail than a PR description.
Re:Git Rebase for the Terrified
by shawndumas on Tuesday January 13, 2026 @05:21PM
(#46609162)
Yes! When you are deep in the code, your brain operates in a non-linear way. You try a solution, it breaks a test. You patch the test. You realize the variable name is wrong. You fix a typo.
Without Squash, the main branch history becomes a timeline of your mental struggle.
With Squash, the main branch becomes a catalog of features delivered.
No body needs to take a trip on the struggle bus with me...
>Why should I look at ten commits when I can look at one and get the same exact data?
For the same reason you have your production history instead of zip file with code)
>while presenting a nice clean set of changes at the end of it
The set, yes, not a single squashed commit.
>The branch is a scratchpad, you should feel empowered within your own branch, rebase
Yes, amend, fixup, rebase. Make it a nice set of small commits.
Most of those 10 squashed commits likely had commit comments like: "Cleanup based on PR feedback." etc.
That's what --amend and --fixup are for.
Re:Git Rebase for the Terrified
by cmrdporcupine on Tuesday January 13, 2026 @06:36PM
(#46610089)
Which wreaks havoc with githubs shitty code review tool.
Which is an argument against GitHub, not clean commit history
Re:Git Rebase for the Terrified
by cluckindan on Tuesday January 13, 2026 @07:44PM
(#46610806)
Yep. Rebase rewrites history and all the PR review comments vanish.
Gitlab seems fine with it
Re:Git Rebase for the Terrified
by cryptonector on Tuesday January 13, 2026 @04:10PM
(#46608069)
I think one should be allowed to push commits that don't build or pass tests provided a) they are marked as such (so you can skip them sooner when bisecting) and b) the HEAD commit after each push does build and pass tests.