CODEWITHSUNDEEP
git
anio
anio

Reputation: 9161

Should I prefer git merge or git merge --squash

I've been going back and forth and can't quite decide which workflow is better. Should I prefer to squash branches that are merged into master. Or should I just merge them.

I favor merge -squash and have been using it consistently.

Pros for merge --squash:

  1. Cleaner history.
  2. Easier to use bisect.

Are there any reasons I shouldn't be using merge --squash and use plain old merge instead?

Upvotes: 3

Views: 3845

Answers (2)

Schwern
Schwern

Reputation: 164679

It depends.

Squashing loses information, and whether to squash depends on whether that information is important or not. Important to somebody six months or six years down the road trying to figure out why a line of code is the way it is. That depends on what was in the branch, the number of changes, the size of the changes, and how good the log messages are.

A simple rule of thumb? Consider the result of the squash and ask yourself "if I were coding on master, would I commit this?" If the answer is yes, that the diff and log taken together will allow a person in the future to figure out why a line of code changed, then squash the merge.

If the answer is no, this would not be an acceptable commit to master, there's too much change or too many intertwined changes, then don't squash it. Merge it, perhaps after considering if any commits within the branch could be squashed together.

As to squashing being "cleaner" and "easier to bisect"... I feel that's only true on the surface. If you took out the pages of all the books on a book shelf and sewed them into one giant cover that would be "cleaner" in that you only have to worry about one book now. If they were a bunch of novels which each stand on your own, then its not helping. If they were annual meeting reports, its probably better to have them bound together.

It is easier to bisect in the sense that you're less likely to have a commit which broke the build, but if your bisect lands on a giant blob of change where one still have to puzzle over a large quantity of possibilities which may have cause the problem, its made the bisector's job harder.

Use the same standards to decide whether to squash merge as you'd use for committing to master and you'll do ok.

Upvotes: 7

David Culp
David Culp

Reputation: 5480

A fast forward merge is useful when you want to keep all of the intermittent commits, such as when branching to try something that may not work. It is easier to throw a temp branch away than it is to reset the work branch. When the experiment works though, it is good to fast forward the commits onto the work branch, leaving it as it would have been had the experiment been kept on it.

There is no reason I know of to not squash working commits into a single comprehensive commit with a message that covers all the changes. This, as you've noted keeps the history clean and easier to work with. From what I've seen, it is the preferred method to keep the tree clean.

git merge --squash makes a commit with one parent, so it does not show the connection to the parent being merged in.

-A---------C  <-- `git merge --squash`
  \
   *--*--B

Another option is to use git merge --no-ff (no fast forward) to force a merge commit. this commit will have both parents. The advantage is to keep the tree clean while still having detailed commit history if needed.

-A---------C  <-- `git merge --no-ff`
  \       /
   *--*--B

Both C commits are the same, choose the later when you want to keep B.

Upvotes: 3

Related Questions