A Rebasing Workflow for Git

Slide 1

Slide 1 text

A Rebasing Workﬂow Emma Jane Hogbin Westby - Trillium Consultancy Ltd. www.gitforteams.com https://speakerdeck.com/emmajane/a-rebasing-workﬂow-for-git @emmajanehw

Slide 2

Slide 2 text

A Rebasing Workﬂow Emma Jane Hogbin Westby - Trillium Consultancy Ltd. www.gitforteams.com https://speakerdeck.com/emmajane/a-rebasing-workﬂow-for-git @emmajanehw

Slide 3

Slide 3 text

A Rebasing Workﬂow Emma Jane Hogbin Westby - Trillium Consultancy Ltd. www.gitforteams.com https://speakerdeck.com/emmajane/a-rebasing-workﬂow-for-git @emmajanehw

Slide 4

Slide 4 text

Agenda • the tl;dl • Rant: why I don't like rebasing • Rave: when / why I use rebase • Wrap-up • Q&A

Slide 5

Slide 5 text

the tl;dl too long; didn't listen

Slide 6

Slide 6 text

Why should I rebase? • Because it makes your commit history easier to read, and manipulate. • “Because Joe told me to.”

Slide 7

Slide 7 text

Rebasing is like  a malleable sports re-play. Step 1. Rewind the history of your branch. Step 2. Apply new commits from an outside source. Step 3. Then re-apply your work.

Slide 8

Slide 8 text

Rebasing is like  a malleable sports re-play. Step 1. Rewind the history of your branch. Step 2. Apply new commits from an outside source. Step 3. Then re-apply your work.

Slide 9

Slide 9 text

Rebasing is like  a malleable sports re-play. Step 1. Rewind the history of your branch. Step 2. Apply new commits from an outside source. Step 3. Then re-apply your work.

Slide 10

Slide 10 text

Rebasing is like  a malleable sports re-play. Step 1. Rewind the history of your branch. Step 2. Apply new commits from an outside source. Step 3. Then re-apply your work.

Slide 11

Slide 11 text

When should I rebase?

Slide 12

Slide 12 text

When should I rebase? • Before sharing proposed work.

Slide 13

Slide 13 text

When should I rebase? • Before sharing proposed work.

Slide 14

Slide 14 text

When should I rebase? • Before sharing proposed work. • To update your local working branch.

Slide 15

Slide 15 text

When should I rebase? • Before sharing proposed work. • To update your local working branch.

Slide 16

Slide 16 text

When should I rebase? • Before sharing proposed work. • To update your local working branch. • To split a commit into two.

Slide 17

Slide 17 text

When should I rebase? • Before sharing proposed work. • To update your local working branch. • To split a commit into two.

Slide 18

Slide 18 text

When should I rebase? • Before sharing proposed work. • To update your local working branch. • To split a commit into two. $ git rebase -i edit

Slide 19

Slide 19 text

When should I rebase? • Before sharing proposed work. • To update your local working branch. • To split a commit into two. $ git rebase -i edit rebase -i squash

Slide 20

Slide 20 text

When should I rebase? • Before sharing proposed work. • To update your local working branch. • To split a commit into two. $ git rebase -i edit rebase -i squash rebase

Slide 21

Slide 21 text

How do I rebase? • Squash a bunch of tiny commits into one: $ git rebase --interactive • Bring your local, working branch up-to-date $ git pull master $ git checkout my_local_branch $ git rebase master

Slide 22

Slide 22 text

Groundhog Day Conﬂict?! • Resolve the conﬂict and then immediately save your recorded solution with: $ git rerere • Proactively turn on REuse REcorded REsolution: $ git config --global rerere.enabled true • Bad merge? Git will remember the wrong resolution. Immediately forget how you resolved it with: $ git rerere forget

Slide 23

Slide 23 text

How do I stop rebasing? • If things go right, it will stop on its own. • If there are tears, you can abort. $ git rebase --abort

Slide 24

Slide 24 text

let the rants begin!

Slide 25

Slide 25 text

Rant Why I don’t like rebasing.

Slide 26

Slide 26 text

Historical Revisionism

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

Rave Why I love the effects of rebasing.

Slide 32

Slide 32 text

Making Whole Thoughts

Slide 33

Slide 33 text

Resources for  Good Commit Messages gitforteams.com/resources/commit-granularity.html

Slide 34

Slide 34 text

Converting Conversations to Conclusions

Slide 35

Slide 35 text

Patches vs. Pull Requests

Slide 36

Slide 36 text

Merge vs. Rebase

Slide 37

Slide 37 text

Often drawing the history graph BEFORE running a command will help you choose the right command.

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

Choosing a Strategy • Pull = Fetch + Merge • Merge -> no fast forward (“true merge”) • Merge -> with fast forward • Merge with --squash -> all into one • Rebase -> rewind + replay • Cherry Pick -> copy and paste commits

Slide 42

Slide 42 text

In Summary • The beneﬁts of rebasing are most apparent to projects with multiple branches and multiple committers. • Rebasing allows you to reshape commit history so that you are storing conclusions, not conversations. • Rebasing can be used in place of merge to update a branch and results in a simpliﬁed graph of your repository history. • Rebasing can be used interactively to reshape a series of commits.

Slide 43

Slide 43 text

www.gitforteams.com Emma Jane Hogbin Westby https://speakerdeck.com/emmajane/a-rebasing-workﬂow-for-git @emmajanehw