Skip to main content

Krzysztof Hasinski
git pull with rebase

Please, oh please, use git pull with rebase

This note was originally published on coderwall and

When working on a project you usually synchronize your code by pulling it several times a day. What you might not know is that by typing

git pull

you are actually issuing git fetch + git merge commands, which will result with an extra commit and ugly merge bubbles in your commit log (check out gitk to see them).

It’s much better to use

git pull --rebase

to keep the repository clean, your commits always on top of the tree until you push them to a remote server. The command will apply all your yet-to-be-pushed commits on top of the remote tree commits allowing your commits to be straight in a row and without branches (easier git bisects, yay!).

The result should be similar to

Creidhne:project hasik$ git pull --rebase
remote: Counting objects: 37, done.
remote: Compressing objects: 100% (21/21), done.
remote: Total 23 (delta 16), reused 0 (delta 0)
Unpacking objects: 100% (23/23), done.
   9c56a5a..3e62251  master     -> origin/master
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 3e62251c80998bf744f35d0d8e732e2cff01e072.

Note the “rewinding head to replay your work on top of it…”. It means that your commits are rebased onto current remote HEAD.

If you want to merge a feature branch it might be wiser to actually merge your commits (thus having a single point of integration of two distinct branches).

Conflict resolving will be now per commit basis, not everything-at-once, so you will have to use

git rebase --continue

to get to the next batch of conflicts (if you have any). On the upside your commits will still be on top of everything so you can change, rearrange or remove them before pushing your version to a remote repository.

NOTE: Because of many discussions about this note. I DO NOT encourage rebasing remote (public or shared) branches. Rebasing local history is OK (it’s more than OK, it’s sometimes necessary to maintain a clean history), but changing other people commits history is considered a bad practice.

author: Krzysztof Hasiński

Share:Share on FacebookTweet about this on TwitterShare on LinkedInShare on Google+Pin on Pinterest

Like what you see?

Get in touch! We'll respond quickly, and we'll keep your data confidential.