Merge

VS

Rebase

Merge

  • non-destructive
    • existing branches are not changed
  • extraneous merge commit 
    • pollute the branch history
$git checkout feature

$git merge master
        

always merge onto yourself

(not onto others)
i.e. first checkout the branch where you want your commits to end up 

# always make sure you are up to date before such actions
git fetch
git checkout master
git merge iss53

Demo

  1. Felt

  1 Merge branch 'master' of /Users/oh-kpond/feature
  2
  3 # Please enter a commit message to explain why this merge is necessary,
  4 # especially if it merges an updated upstream into a topic branch.
  5 #
  6 # Lines starting with '#' will be ignored, and an empty message aborts
  7 # the commit.
commit 42b6322d5a3707b1492a859d71462cebbde7706b
Merge: dc18666 101cc36
Author: Kate Pond <kate@thepondsedge.com>
Date:   Thu Oct 22 10:52:41 2015 -0400

    Merge branch 'master' of /Users/oh-kpond/feature

"git pull" does a "git fetch" and a "git merge"

FYI

If Rebase were a person

Rebase

  • clear branch history
    • ​perfectly linear project history
  • loses the context provided by a merge commit
$git checkout feature

$git rebase master
        

Demo

  1. Felt 

git checkout feature # remember to always made changes onto yourself
git rebase master

conflicts are solved commit by commit as they are applied

git add <file> # to mark resolution
git rebase --continue

git pull

VS

git pull --rebase

  • git pull = git fetch + git merge against tracking upstream branch

     

  • git pull --rebase = git fetch + git rebase against tracking upstream branch

do NOT rebase if...

  • You are on a public branch

  • Any of the commits been already pushed to server (it is Thursday at 17:45 and don't feel like making enemies out of your coworkers)

Interactive Rebase

Improve your branch before pushing

# Change your commits interactivelly
$ git checkout your-branch
$ git rebase -i master

Know Your Heads

$ git rebase -i HEAD~4 # allows to squash last 4 commits into one
git rebase -i HEAD~3
# now change the output you get:
pick 5c43c2b [Description for oldest commit]
pick b8f3240 [Description for 2nd oldest commit]
pick c069f4a [Description for most recent commit]
# into:
pick 5c43c2b [Description for oldest commit]
squash b8f3240 [Description for 2nd oldest commit]
squash c069f4a [Description for most recent commit]
# thus creating a single commit with all the same changes
# and even have the ability to make a new message for it

Seen Another Way

RULES OF THUMB

  1. Discuss for each project how to tell your story
  2. Use rebase locally to pimp your history
  3. Use merge to preserve your feature branches

Interesting/Helpful Slidedecks

  • http://slides.com/zhaomengru/deck#/
  • http://slides.com/caesar-ralf/deck#/
  • http://slides.com/apottere/git-branching#/
  • http://slides.com/ruslanoid/git#/
  • http://slides.com/arneclaassen/git-rebase#/
  • http://slides.com/annamoragarrido/deck#/
  • http://slides.com/borjagorrizhernando/git-in-context#/
  • http://slides.com/victorpoluceno/deck#/
  • http://slides.com/jschomay/git-fu#/

(many thanks to these folks for letting me use photos and text!)

Other Resources

Don't Be Scared To Try It Out

Thanks!

Made with Slides.com