Two Years of Squash Merge (2019)

So, if your PR has a clean history in the first place (clean as in multiple small digestible, atomic commits, that are easy to review in isolation), why get rid of it with a squash?

Is there a fundamental drawback to keeping that clean history? _It's already here_

It's entirely not insane _on the premise that the history is clean_. That's the whole argument that is being made here.

If you think that "Preserving a PR's individual commits in the master branch is insane - many of those commits won't represent a fully working system anyway", your issue _is_ "that your commits don't represent a fully working system anyway", _that_ is what you need to fix.

You need to make sure your history _does_ represent multiple small digestible atomic chunk of codes, that are understandable individually.

By squashing, you're not fixing the root cause, you're treating the symptoms.

I guess I haven't worked on a project important enough where the history is more important than the current state. Usually it's more like it might be useful to gain perspective by looking at the history, only to find it was a conflicted merge or the comment contained no useful info anyway ("Clean up", or "Fix this feature").

Even if it tried really hard to document the purpose of the change, I've rarely gotten more from a commit message than the content of the code changes in the commit.

Until you have done it it may sound like an incredible amount of effort but in fact it isn't at all. Your reality might be different, but we also deal with different time zones. In this particular example the other team was in a different time zone and already gone for the day. The easiest and most efficient way was a 'dumb' bisect.

If you _only_ raise it to the team in question, you have nothing in hand but suspicions. Their natural reaction is most probably going to be "No can't be us, must be something/someone else" and you've wasted an entire day waiting for their response that was predictable anyway and you've also just increased both their and your own irritation level. Their's because they probably feel like you're trying to blame them for something they feel is not their fault. Your own because you've just wasted a day trying to solve this and meanwhile customer service thinks you caused a regression.

A bisect that literally took zero brain cycles and told me which commit caused it before I was even halfway done with my meetings allowed me to let them know exactly which commit caused it without a doubt (unless your company is so broken that they wouldn't even believe the bisect output :)). This also gives them very valuable information because instead of them now trying to have to figure out which of their changes maybe caused this thing I'm 'accusing' them of, they have a single commit, which is directly tied to a single ticket. In this particular case, the developer in question actually knew right away from seeing the commit message/ticket number what particular part of their change was the cause of the issue, without even having to dig through the code.

> You can use short-living branches to avoid repetitive merge of master

> No, this doesn't work. It does if you have very few developers, each working on individual branches. But when multiple developers are working on multiple-feature branches together, that doesn't scale. We encourage backporting master often into your branch to limit the risk of conflicts, and stay on top of the latest changes. For example, we continuously update dependencies. We also merge and ship on average 10 times a day.

Those are development branches that should be treated like master/main and developers should be writing short feature branches which are merged into those branches.

And in the simplest case when you start work on N+1 then that becomes your main branch, and you fork off the stable N branch. Both of those are treated the same and devs should do PRs into them. Those PRs should ideally be simple things that are easy to review which should be single commits. This enables squash+rebase on those daily private branches.

You can also fork off a nuclear reactor branch which is long-lived, occasionally merge back from the main branch and then merge into main later. I'd discourage that since you have the issues of merging and porting, potentially both ways. But again you shouldn't have devs directly committing to that branch and then pushing, they should be opening PRs of their work into it, when its merged, then other devs can pull that branch and rebase their local work on top of it.

I've helped out individual devs with commits on top of their feature branches from time-to-time, but I consider that they've got the ultimate "write lock" on those branches. Typically as a result of actually chatting with them in zoom sometimes it might be faster to just push a commit with the work. But once that is done, its their private branch again, and I expect them to rebase and for me to have to deal with that if I look at it again.

EDIT: Also the long-lived feature branches are going to be impossible to adequately review when it is time to merge them back into main. That code review needs to be happening all along the way if that is your process. You can't adequately review 4 months of work by several devs once at the end of it all. They need to be doing that the whole time. That calls for a branch they're doing their own PRs and code review into.