Re:Fortunately, I don't squash my commits
by swalsh on Monday October 05, 2020 @08:00AM
(#24686869)
I do, all the time. I highly recommend others do it too. I like to keep to 1 commit per ticket (even a super large ticket that might take me weeks of development). But having a commit history like the fella in this story is nice too. So what you should do is work in a feature branch. On the day of deployment I'll squash, and cherry pick (in my case to a train). If the deployment goes bad, and my code is at fault, then all that is required to fix it is a single revert.
[ Parent
| on HN ]
Re:Fortunately, I don't squash my commits
by mfontani on Monday October 05, 2020 @09:13AM
(#24687445)
You get a similar benefit (a single revert to revert it all) via "git merge --no-ff BRANCH". If the BRANCH is a fast-forward (i.e. it's been rebased to master/main & tested before merge) then you get both benefits of a clean history and an easy revert, for little downside.
Keeping the history of each incremental change, even in a branch, is IMO too useful to give up.
Note I'm not advocating keeping those "fixed typo in previous commit" fix-up commits: those should be properly fixed up _before_ merge, by judicious use of git rebase.
Re:Fortunately, I don't squash my commits
by Joker_vD on Monday October 05, 2020 @08:41AM
(#24687183)
Wait, I must be missing something. I too develop in feature branches, and then they're merged into develop or main (with a merge commit, obviously). Reverting that is too only a single revert. The only problem is that sooner or late those feature branch do get deleted, and if you swashed, you lose all the non-squashed history. If you don't, it's still in the develop/main branch.
What do I miss?