I’ve worked on multiple codebases where nobody on the team had been there when the sausage was first made. The squash commits are some of the worst commits for finding out why a weird design decision was made because all the things that came out in code review or would have had bugfix commit messages in their local branch are all squashed together in one commit. CRs help a lot but frankly I do want to know how the sausage was made when I’m look through the git history or else I would just look at the code directly. Especially when I’m investigating some bug in prod.

I don’t quite understand what you mean. As I wrote I write my PR message as the commit message. That is one thing that is also very important for me. Write in the commit message why something changed. If the PR gets so damn big that it is so much to explain everything than it’s quite frankly too big. From my experience the follow up commits for fixes or code review changes boil down to messages like “fix stupid bug”, “adjustments after code review”, etc. which are also not helpful when looking for the why. But I honestly understand what you mean. I’m just saying that limiting down the number of commits and the size of changes in them helped me over the years. I also don’t do it when I start of from a white paper. Only when the project enters the stage when PRs plus checks help mitigate potential bugs etc.

> The reason why I prefer squash commits is not only the linear history but also the fact that I’m simply not interested in the sausage making process.

I see this a lot and in my opinion squash on merge is just a very poor version of using rebase to put your commits into a proper state before merging.

A commit should be one logical set of changes. It's great if you can get a piece of work done in one change, but often larger work requires several changes.

Beginners seem to treat pull requests as places to pile commits until you get something reasonable at the end (the sausage making process). A better way is to curate your work and clean up the individual commits as changes are requested in review. Then you have a coherent history with commit messages that might tell you something useful.

There is another angle I forgot to mention. That is that I also want that each commit can be compiled (depends on the project obviously) and is tested and won’t fail tests. That is super hard to achieve when only testing the last commit of a PR through a push. I mainly want that to help when bisecting. That’s what I achieve by smaller PRs. But again I personally prefers this and lay out my projects and tasks in a way that this actually works for me. I’m not Dogmatic and see the reason for different strategies.

> that I’m simply not interested in the sausage making process

Sure, no one really cares about they sausage making process, but tracking down regressions is so much easier with a proper history. Bisect is your friend.

Sincere question: does a “squash merge” implicitly include a rebase as well when the merge target has diverged?

It's equivalent to rebasing, and squashing into a single commit.

It's also equivalent to a merge commit, and then only keeping the diff from the merging in branch.

So it's sort of a half way house, and sort of the worse of the both worlds.

Yes it has it up and downs. But it also helps me and my team to enforce smaller patches since they land as one anyways. And other teams in my company follow the open PR and develop the next 2 weeks on it and merge in full. There is so much garbage in all these commits no one ever wants to get back to. Good luck bisecting on of these histories.

How independent are those commits? If I'm developing a feature that has distinct but dependent changes, then the rebased/squash pattern doesn't work as well. Submitting in a single PR means that those distinct changes all get squashed away. Submitting in a series of PRs keeps the history, but means that the have commits on main have different ids, and so I need to keep using `git rebase -i` to remove the corresponding commit from my dev branch whenever one gets merged in.

GitHub is pretty smart nowadays. If you propose a series of PR on top of each other, GitHub will change the base when it the base of the second PR got merged and so on. There is sometimes the need to rebase but I have generally no problem with it. Mind that I don’t propose this workflow with teams that also have non tech members like artists because these Workflows bring too much friction. But I keep my changes as independent as possible. All running with tests to cover the added/changed code.

It means using `git merge --squash` which performs a normal merge but then instead of adding a merge commit, it just makes a single regular commit with the changes.