How to Squash and Rebase in Git

There are two exceptions.

1. branch developer suffered from several "thinkos" along the way, the branch doesn't contain that many changes, and there's simply no benefit to seeing the contrast between the initial (mistaken) changes and the final result.

2. the branch commits create a situation where git bisect can't be properly used because intermediate commits will not compile. Squash is one option here, though it is often preferable to just re-branch and re-work commits to avoid both the bisect problem and the squash.

With a 21 year development history, we have found it invaluable to be able to trace the "thought processes" behind a series of commits, and squash would rob us of that.

Not really. The secret is to rebase fairly often, at the very least daily (depending on the size of the organization you work in, this could be more often). I often see complaints like this from junior devs. They work in isolation on their branch for a week, and then they complain about how hard it is when they try to do a rebase on top of the 100+ commits that happened while they were out there doing their own thing.

Another common issue comes from not understanding how rebase works well enough. You are supposed to adjust just the changes of this commit, not take anything else into account. If you start making unrelated changes when rebasing, your commits will soon conflict with each other, which means you'll run into a lot of very confusing conflicts.

It's fine to squash before a rebase if you are not interested in the history of your branch. But if you are, it's just not an acceptable solution.

Git history management can be tricky business, and most teams have their own norms, as this discussion shows. What matters most of all is that everyone on your team learns and feels supported with your chosen git processes, including junior devs, and that you have some consensus on it.

For anyone who is overwhelmed by the options and syntax, one of my friends swears by Fork, for those who prefer a GUI over doing git by hand. It has its own learning curve, but works better for some devs.

What’s more, I also want only commits that relate to the feature implemented on the branch. Preferably no merges from the parent branch.

To get zero oops commits requires squashing in the branch. Note that this is independent of whether the branch is merged or squashed when the PR is completed. Squashing 10 branch commits to 3 is the important step. If those 3 are squashed to a single on the target branch is less important and is a tradeoff.

As a developer I’ll not care to maintain build/testable code on feature branches, which is my main reason for usually squashing to the target branch. For larger changes I merge (after cleaning up and interactively rebasing), but git bisect will have to use —first-parent to work.