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:
- 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 firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at