Git pull results in extraneous "Merge branch" messages in commit log

git github commit
mshafrir picture mshafrir · Dec 14, 2011 · Viewed 50.8k times · Source

I'm working with another developer on a project, and we're using Github as our remote repo. I'm on a Mac using git 1.7.7.3, he's on Windows using git 1.7.6.

This is what's happening

  1. One of us (let's call him developer A, but it doesn't matter which one) pushes a set of commits to GitHub.
  2. The other (developer B) makes some local commits.
  3. B does a git pull.
  4. B does a git push.
  5. Looking at the commit history log, I see Merge branch 'master' of github.com:foo/bar

The commit log gets littered with "Merge branch" messages over time, and also shows developer B as committing changes that developer A made. The only way we've found to prevent this issue has been to do a git pull --rebase at step 3, but I don't know what side effects rebasing will introduce. This is my first time working on a multi-developer git repo, so is this just normal behavior? Any thoughts on how to solve this issue?

Answer

poke picture poke · Dec 14, 2011

The commit you are seeing is perfectly fine. A pull effectively runs git fetch and then git merge so a merge is usually happening when you run git pull.

The alternative to use rebasing instead of merging is possible, but usually you should avoid it. Rebasing allows you to keep a linear history, but also removes any information about the branching that originally happened. It will also cause the history of the current branch being rewritten, recreating all commits that are not contained in the target branch (in your case, the remote). As the recreated commits are different commits, this can cause a lot of confusion when developing together with others, especially when people already checked out parts of those commits before they get rewritten (for example with feature branches). So as a rule of thumb, you should never rewrite any commit that was already pushed.

The commits you see are there to combine two (or more) branches. It is perfectly fine to have a commit that does nothing else then merging multiple branches. In fact it makes it very clear when you have a merge commit that combines branches when looking at the history. In comparison to rebasing, merging also allows you to effectively see the original history as it was developed, including the actual branches that coexisted.

So, long story short: Yes, having merge commits is perfectly fine and you should not worry about them.

Related questions

Editing the git commit message in GitHub

Is there any way of online editing the commit message in GitHub.com, after submission? From the command line, one can do git commit --amend -m "New commit message" as correctly suggested in another question. Trying git pull and then …

Read More
Why Git is not allowing me to commit even after configuration?

This question seems like a duplicate but it's really not. Just a slight difference that keeps on repeating. git keeps on telling me: "please tell me who you are", even after setting it up. when I run git commit, this …

Read More
How do I reverse a commit in git?

I'm not really familiar with how git works. I pushed a commit by mistake and want to revert it. I did a git reset --hard HEAD~1 Beware Fellow Googlers: This does not only revert the commit, but discards all file …

Read More