So there you are, using git to store, track and share your code with a few others. Maybe many others. You make a change, someone else makes a change, one or the other of you pulls the others changes and BAM.. you get that merge commit. It really isn’t harmful of course, but it cleans up your repository a lot to get rid of them. So…
- When you pull, use –rebase.
git pull --rebase
There. It did it for you. All your commits go after the commits on the remote origin.
- You forgot to do that. No prob…
git pull # oh man.. I forgot.. merge commit git rebase origin/master # There. Pretty easy isn't it.
So of course, you might have the same issue if you were working on a branch. You check out master, make some commits, go back to your branch, make some more, etc. It works the same way.
# on your branch git rebase master
There. You can pull in the master branch changes but put all your branch changes after so you don’t have to have the merge commit again.
So you wrote that branch, changed master, and then you merge your branch back to master and get a merge commit again. In this case there isn’t a ref to rebase off of so intuitively like remote/origin or master. No prob, just use gitk or git log or whatever to find out what the sha1 of the old master was before you made your merge.
There. No merge commit again.
Now, there are a bunch of more advanced things rebase can do. You can use it to edit commits that weren’t quite right. You can also change the order of commits, edit the commit message, drop commits completely, and other cool things. You can do it all interactively too…
git rebase -i
# fun for all!
I leave you to study that part on your own.