Hi Brad,

The first merge commit there is a fairly typical occurrence: You have done 
some local commits, while the remote master branch has diverged (i.e. other 
commits have taken place there). Upon merging, Git cannot fast forward, so 
it creates a merge commit, saying it is merging the branch origin/master.

This is not a nice merge commit. Merge commits are better (meaning more 
readable for humans) when they read like "Merging new-feature-x to master". 
What you should do here in your workflow, is to *rebase* origin/master 
instead of merging it, because you want to put your local commits *after* the 
ones that have happened in origin/master.

So, next time you have local commits, and you want to update, do this:

1) git fetch
2) git rebase origin/master

Regarding the second, older merge commit, I'm not really sure how it came 
to be. It looks like you had a branch mis-named as "origin", and did some 
"merge master origin/origin" or something. If you can remember what 
commands you where doing here, we might figure it out.

Anyhow, I know this sounds tricky, and it is. Git's principle of remote 
branches is however very powerful when you get on top of it. I recommend 
reading these articles:

   - http://www.gitguys.com/topics/adding-and-removing-remote-branches/
   - Unfortunately, the above two articles don't mention rebasing, so look 
   at this one: http://gitready.com/intermediate/2009/01/31/intro-to-rebase.htm

Also, here's a nice command for seeing what your history looks like 
graphically (better yet, use some Git GUI tool for looking at the history):

git log --graph --oneline --decorate --all

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To view this discussion on the web visit 
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to