I used to suppose squash commits have been so cool, after which I had to make use of all of them day, day by day. Right here’s why you must keep away from squash
“Wow, that’s so cool!”
I’ll at all times bear in mind seeing my first squash commit.
After I first joined a big engineering group with greater than 200 members, the squash commits have been the very first thing I seen.
To me, the constant use of squash commits throughout the corporate screamed “professionalism” and “we all know what we’re doing right here!”
It took me a couple of month to understand that I actually, actually didn’t like squash commits, and I began eager for good, old style merge commits.
As a refresher, the distinction between a “squash commit” and a “merge commit” is {that a} common “merge” consists of the entire Git commits within the historical past of the goal department, whereas “squash” flattens them to at least one commit.
Confusingly, “squash” isn’t its personal command. As a substitute, you may select “squash and merge” or “squash and rebase” as an choice whenever you’re working the git merge or git rebase instructions, respectively.
By default, a pull request (PR) will probably be a merge commit, so after the PR is merged then your complete historical past of the working department will probably be merged in, plus an extra commit (“Merge pull request #21 from department…”).
Then again, you may set your repository to “squash and merge” by default, that means merged PRs will end in solely a single commit every, as a substitute of bringing over all of the commits from the working department.
The good thing about squash commits is that you simply maintain a “clear” Git commit historical past. Since we builders are famously… let’s say “exact”… then a tidy commit historical past sounds completely incredible. It’s not.
You possibly can see why I used to be impressed by the professionalism — your complete engineering group was so devoted to having a clear commit historical past that they’d mandated “squash and merge” because the default!
Sadly, the advantages of getting a clear commit historical past finish precisely proper there — the historical past could also be clear, however my day-to-day work wanted way more context than what a squashed commit might present.
By definition, a squash commit loses info. I like to consider it as a black gap, the place the knowledge will get become “Hawking radiation,” which on this specific case is measured in items of developer frustration.
I quickly grew to become disillusioned with squash commits for the straightforward motive that my job was 90% fixing bugs in outdated code. After I would examine a line utilizing Git Lens to run git blame, I’d by no means study the whole lot.
Actually each git blame on the firm learn, “Merge pull request #237 by {my boss or coworker},” with no further info. I couldn’t even discover the subject of the PR with out trying it up manually! How irritating!
I’d dutifully pull up the unique PR and ticket, attempting to get some sense of why this specific line of code modified, and I’d do not know. You know the way a PR usually modifications a whole bunch of traces of code without delay? Yeah…
I can depend on one finger the variety of instances I wanted to truly revert a complete squashed commit without delay, and it was a dramatic rollback of a PR that pushed our complete roadmap again by a complete month.
The remainder of the time, I’d be doing my regular work, attempting to repair bugs with a deadline of “are you able to get this to QA by finish of day?” And after I’d examine a line, I’d do not know why it was modified, due to the squash commits.
Look, I’d love a clear commit historical past, too, however the downsides are crippling to day-to-day work. Whereas it’s nice to know “this broke when fixing this different bug,” a squash commit doesn’t give me sufficient information.
Let’s say I do know my boss modified a sure line of code 18 months in the past by inspecting it with git blame. At this level, he certainly has no thought why he modified it, even when he might discover the time to research it for me.
With squash commits, I’m left with much less info: I can solely discover out the bugfix or function that resulted within the line being modified, not the precise motive the road was modified, and that’s simply not sufficient to go on.
Whereas it might be nice if each line had a code remark or two, everyone knows that’s not how most builders work — I usually see lower than 1% of code really having any feedback after I take a look at a brand new React codebase.
The rationale I do not know why the code modified is fairly easy; my boss wrote down the rationale on the time (within the commit message), however then we determined to “squash” it away for no motive. That does not spark pleasure.
There’s a brilliant easy resolution right here, and it’s really the default — simply don’t squash. What I wish to know isn’t a lot, but it surely makes all of the distinction:
- refactor: Was my boss “refactoring” this code to be extra readable or maintainable, hopefully with out affecting the precise performance?
- chore: Was my boss performing some cleanup “chores” that shouldn’t have affected the manufacturing code, reminiscent of including code feedback or exams?
- repair: Was my boss “fixing” an recognized difficulty, and in that case what was the particular difficulty that was damaged with this piece of code?
- feat: Was my boss implementing a brand new function, reminiscent of making a brand-new part with user-facing performance?
Did you decide up on the truth that these are Typical Commits (additionally known as “semantic commits”), that are finest paired with atomic commits?
The rationale I grew to become so disillusioned with the corporate is that there was an excellent tradition round commit messages, however a horrible one round PRs.
Since we had super-long JIRA tickets, there wasn’t an excellent motive to jot down a lot in a PR, however then we threw away all of our context by squashing.
The outcome was we’d spend actually hours attempting to repair bugs as a result of nobody remembered what any given piece of code was imagined to do.
So, at my present firm, I make dozens of commits a day, and I go away all of them within the historical past after I merge my PRs. It might be a bit of messy, but it surely’s higher for my sanity, in addition to for my GitHub contribution graph.
Comfortable coding!
P.S. In case you appreciated this sizzling tackle Git finest practices, then you definately’ll love me attempting to persuade you to jot down 200-character commit messages, proper? Learn this:
