[dankohn1]

We use a more extreme version of rebasing feature branches before merging into master: we squash the features into a single commit when merging to master. The reason is that we don't care about the (sometimes hundreds of) commits that made up a feature. What matters is that it works as designed and passes tests. If we merge a feature to master and then need to revert it, we will revert the whole feature.

This also allows us to keep merging master into feature branches, (where there is only a single commit that might need to be manually merged) instead of rebasing feature branches on master (in which case it can be necessary to manually merge multiple intermediate commits).

What cleared up git merge --squash for me was a comment showing that:

  git checkout master
  git merge --squash feature

is the equivalent of doing:

  git checkout feature
  git diff master > feature.patch
  git checkout master
  patch -p1 < feature.patch
  git add .

[Thrymr]

That loses a lot of information, though. If you want to bisect to find a particular bug, tracking it down to the merge is a good start, but I'd rather have the actual commit (from the maybe hundreds) that went into the merge. Sure, you can revert the feature, but what if you want to fix the bug?

Git history has a lot of commits. That's OK.

[dankohn1]

Yes, the downside of a much more streamlined commit log is that we do throw out information.