git-pull-rebase.md

Lately I've seen a lot of git commits that say:

Merge branch 'master' of http://git.labs.sabre.com/git/rails

Or while on a feature branch called add-toggle:

Merge branch 'add-toggle' of http://git.labs.sabre.com/git/rails

These are typically trivial merge commits that don't provide much value when going through the git log, so I'd prefer not to see them. You'll see them when using a visual tool like gitk or SourceTree, which I do pretty often throughout the day.

Bad scenario

Here's the sequence that makes this happen:

• Commit some changes locally to master

• Activity has happened on the remote master, your branches have diverged

• You need to update so that you can push, so you do a git pull

• You do a git push

The merge commit is all of the commits that have occured on the remote master since you last updated your local master.

Simulate it yourself:

Here's how you can simulate it see it in action:

• Get set up and make your local master behind origin by two commits:

  • git checkout master
    • git pull origin master
    • git reset --hard HEAD~2

• You're now "behind" remote, so make a commit:

  • touch something.txt
  • git add .
  • git commit -am 'adding some stuff i shouldnt be to master'

• Do a git status and note "diverged"

    # On branch master
    # Your branch and 'origin/master' have diverged,
    # and have 1 and 7 different commits each, respectively.
    #   (use "git pull" to merge the remote branch into yours)
  

• Do a git pull like it says

• See the useless merge commit

Ideal scenario

In the real ideal scenario, you don't commit changes to master, but here's what you do if you are anyway.

What you're going to do is use git pull --rebase. What this does is take your commits, set them aside, reset your master to what's on origin, then lay your commits back on top.

Simulate it yourself:

Here's how you can simulate it see it in action:

• Get set up and make your local master behind origin by two commits:

  • git checkout master
  • git pull origin master
  • git reset --hard HEAD~2

• You're now "behind" remote, so make a commit:

  • touch something.txt
  • git add .
  • git commit -am 'adding some stuff i shouldnt be to master'

• Do a git status and note "diverged"

    # On branch master
    # Your branch and 'origin/master' have diverged,
    # and have 1 and 7 different commits each, respectively.
    #   (use "git pull" to merge the remote branch into yours)
  

• Do a git pull --rebase

• Notice that your commit looks like it is freshly made on top of a synced master.

Real ideal scenario

The real ideal scenario is that you're using feature branches, and your local master is always clean and able to do a simple git pull. It will do what's called a fast forward, since the branches aren't divergent.

You check out master, update it (which is clean and not divergent), merge your feature branch, then push changes.

Steps:

git checkout master

git status Says something like: … and can be fast-forwarded.

git pull origin master

git merge feature-branch

git push origin master

Tips:

DON'T do a git pull --rebase after you do a git merge. It will replay all the commits from the feature branch on top of master as though you did them directly in master.

Summary:

If you do git status:

" and can be fast-forwarded."

Safe to do a simple git pull

"Your branch and 'origin/master' have diverged"

Do a git pull --rebase

Check the way things look before git push

Warnings:

Don't do git pull --rebase after doing git merge