Slide 1

Slide 1 text

GIT rebase vs. merge

Slide 2

Slide 2 text

CURRENT STATE C0 C1 C2 master

Slide 3

Slide 3 text

NEW BRANCH C3 new_feature C0 C1 C2 master

Slide 4

Slide 4 text

CHANGES ON MASTER C3 new_feature C4 C0 C1 C2 master

Slide 5

Slide 5 text

MERGE C3 new_feature C4 C0 C1 C2 master C5

Slide 6

Slide 6 text

PREVIOUS STATE C3 new_feature C4 C0 C1 C2 master

Slide 7

Slide 7 text

REBASE C3 new_feature C4 C0 C1 C2 master C3’

Slide 8

Slide 8 text

FAST-FORWARD MERGE new_feature C4 C0 C1 C2 master C3’

Slide 9

Slide 9 text

EXAMPLE

Slide 10

Slide 10 text

REAL WORLD EXAMPLES

Slide 11

Slide 11 text

REBASE VS. MERGE + flat and readable history + simple single commit manipulation + intuitive - more complex - can be dangerous - rewriting history + simple to use + maintains original context - create clutter when multiple people on the same branch - intensely polluted history with merge commits - harder to use git-bisect

Slide 12

Slide 12 text

CONCLUSION • rebase when possible • rebase PR before merging • merge PR on GitHub • always pull with rebase: http://stevenharman.net/git- pull-with-automatic-rebase