Comment by foobarbecue
3 days ago
Github default squash commit template & merge strategy makes it easy to go from the squash commit to the feature branch. So you get best of both worlds -- clean master and granular history on the branch. Bisect on master tells you which branch broke it, and then bisect on the branch if you want to find the original commit. Same with blame.
IMO squash 4 the win. Github squash defaults work well. Gitlab squash defaults don't.
Imagine a feature in git, where when you merge, you get a single new commit on the main branch like you want, where the message could describe the changes in summary, like you want. But also: the commit contains a reference to the source branch so you can easily find it back, break it down, bisect into it, all without having to leave git or rely on data stored at 3d parties. That would be pretty neat! It's like, the best of both worlds, but all inside git!
Well. That's what a merge commit is.
Your approach is nearly identical to creating a merge commit, except the pointer to the second parent (the "original branch") is indirectly recorded via the PR link, instead of directly inside git.
If you create merge commits, then you have your "clean main branch" (via git log --first-parent), as well as the extended history with all the source commits (via git log). And as a bonus, merge commits are supported by every git host, and they work the same in all of them.
I think the whole "squash merge vs merge commit" discussions would be a lot less prevalent if --first-parent would be how git and git hosts displayed commit histories by default. :(
That's interesting, so you keep the branches from before the squash -- but do you also rename them somehow, to show that they're now "frozen historic versions"?
That’s what I do, and I find this talk about “throwing away” code history baffling. It’s version control. Git branching is cheap.
I make a ton of backup copies. I rearrange the history to how I want before I share it (git history split is great). I keep my nonsense, others see a readable changeset. (Only downside is the occasional housecleaning of old branches, but after a while their usefulness diminishes.)
Actually, what I usually do in Github is set the PR branches to delete when you squash-merge the PR, but then the PR always has an "undelete branch" button you can use forver in case you want to look at the details of the branch and don't have a local copy of the branch.