44

If I am working in multiple branches on a single feature, I use git pull branch1 branch2 branch3 to pull all the changes into my master branch. However, all the commit logs of each branch are copied as well. How do I flatten the commit log down to a single message?

pmaruszczyk
  • 2,157
  • 2
  • 24
  • 49
Verhogen
  • 27,221
  • 34
  • 90
  • 109

3 Answers3

73

"git merge --squash" (after "git fetch"; "git pull" is just fetch+merge, pehaps it also allows --squash option) might be what you want.

From git-merge(1):

--squash

Produce the working tree and index state as if a real merge happened, but do not actually make a commit or move the HEAD, nor record $GIT_DIR/MERGE_HEAD to cause the next git commit command to create a merge commit. This allows you to create a single commit on top of the current branch whose effect is the same as merging another branch (or more in case of an octopus).

Jakub Narębski
  • 309,089
  • 65
  • 217
  • 230
28

You can use interactive rebase and "squash" the commits -- see also the Git Ready Tutorial on squashing via rebase. Sorry to just dump a link on you but that's a pretty thorough tutorial. Oh, and this will also squash away your merges just fine.

bstpierre
  • 30,042
  • 15
  • 70
  • 103
Pat Notz
  • 208,672
  • 30
  • 90
  • 92
  • 12
    Interactive rebasing is not the only way. The easier way would be to simply `merge --squash` as mentioned in the other answer. The effect (i.e. dump all changes from branch as single diff on current branch) would be the same, but with half the work. – Yuval Adam May 01 '11 at 15:03
  • 5
    The problem with `git merge --squash branch && git commit -m "message"` is that it does not actually mark the branch as merged. `git branch -d` won't remove it (use `-D`) and graphical viewing tools will show the branch just hanging instead of being joined. – Brian White Jan 15 '14 at 02:02
12

As Brian White commented the problem with git merge --squash is that it gives you no visible link, and therefore no traceability back to the branch (or the individual changes) you merged in.

Visibly (when viewed as a graph git log --graph), an important branch that has been merged back in looks no different to an experimental branch that you messed around with and would happily discard. Both are just hanging there unconnected to anything. I personally want to know that a certain branch has been merged back in so I know that work is done.

A solution that works for me is to use a merge with the no-fastforward option.

git merge --no-ff somebranch -m "my commit message"

This forces git to create a single commit with all the branch changes included, you can set the commit message yourself (if you want) BUT most importantly, it links the new commit back to the branch it just merged in. This visibly shows that work on that branch is complete but also allows you to trace back to see details of the individual commits from the merged branch.

Here is an example where very simple branches with one and two commits respectively have been merged back into master. I have subsequently deleted the branch tags on the merged branches, however the branch name can still be seen on the merge commit message. The branch name should summarise the changes and if you want to know the exact changes contained you can trace it back to the individual commits. This approach seems to work nicely for simple projects.

Note : I had to manually draw one of the connectors in as it was such a dark blue it was barely visible.

git log output

samaspin
  • 2,342
  • 1
  • 26
  • 31
  • Not sure if my situation is different than yours but this didn't work for me. It just did a normal merge with all the commits from the branch being merged in, not squashed. – Patrick Goley Feb 07 '23 at 22:32