Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Git merge flattening

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?

like image 786
Verhogen Avatar asked Apr 23 '09 22:04

Verhogen


People also ask

Should you squash commits before merging?

Before you start, keep in mind that you should squash your commits BEFORE you ever push your changes to a remote repository. If you rewrite your history once others have made changes to it, you're asking for trouble… or conflicts.

Do I need to rebase before merging?

It's simple – before you merge a feature branch back into your main branch (often master or develop ), your feature branch should be squashed down to a single buildable commit, and then rebased from the up-to-date main branch.

Should you squash commits when merging into master?

As a general rule, when merging a pull request from a feature branch with a messy commit history, you should squash your commits. There are exceptions, but in most cases, squashing results in a cleaner Git history that's easier for the team to read.


3 Answers

"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).

like image 56
Jakub Narębski Avatar answered Oct 31 '22 14:10

Jakub Narębski


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.

like image 40
Pat Notz Avatar answered Oct 31 '22 15:10

Pat Notz


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

like image 12
samaspin Avatar answered Oct 31 '22 14:10

samaspin