Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Rebasing Workflow for Git

A Rebasing Workflow for Git

You've decided to level up your Git skills and have heard that rebasing is where it's at. In this session we'll talk about: WHY rebasing can make it easier to untangle your project's history; WHEN you should use rebase; WHAT rebasing actually does to your repository; and HOW it actually looks when things go right (and how to recover when things go wrong).

Emma Jane Hogbin Westby

February 18, 2015
Tweet

More Decks by Emma Jane Hogbin Westby

Other Decks in Technology

Transcript

  1. A Rebasing Workflow Emma Jane Hogbin Westby - Trillium Consultancy

    Ltd. www.gitforteams.com https://speakerdeck.com/emmajane/a-rebasing-workflow-for-git @emmajanehw
  2. A Rebasing Workflow Emma Jane Hogbin Westby - Trillium Consultancy

    Ltd. www.gitforteams.com https://speakerdeck.com/emmajane/a-rebasing-workflow-for-git @emmajanehw
  3. A Rebasing Workflow Emma Jane Hogbin Westby - Trillium Consultancy

    Ltd. www.gitforteams.com https://speakerdeck.com/emmajane/a-rebasing-workflow-for-git @emmajanehw
  4. Agenda • the tl;dl • Rant: why I don't like

    rebasing • Rave: when / why I use rebase • Wrap-up • Q&A
  5. the tl;dl too long; didn't listen

  6. Why should I rebase? • Because it makes your commit

    history easier to read, and manipulate. • “Because Joe told me to.”
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. When should I rebase?

  12. When should I rebase? • Before sharing proposed work.

  13. When should I rebase? • Before sharing proposed work.

  14. When should I rebase? • Before sharing proposed work. •

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

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

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

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

    To update your local working branch. • To split a commit into two. $ git rebase -i edit
  19. 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
  20. 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 <branch_name>
  21. 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
  22. Groundhog Day Conflict?! • Resolve the conflict 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
  23. 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
  24. </tl;dl> let the rants begin!

  25. Rant Why I don’t like rebasing.

  26. Historical Revisionism

  27. None
  28. None
  29. None
  30. None
  31. Rave Why I love the effects of rebasing.

  32. Making Whole Thoughts

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

  34. Converting Conversations to Conclusions

  35. Patches vs. Pull Requests

  36. Merge vs. Rebase

  37. Often drawing the history graph BEFORE running a command will

    help you choose the right command.
  38. None
  39. None
  40. None
  41. 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
  42. In Summary • The benefits 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 simplified graph of your repository history. • Rebasing can be used interactively to reshape a series of commits.
  43. www.gitforteams.com Emma Jane Hogbin Westby https://speakerdeck.com/emmajane/a-rebasing-workflow-for-git @emmajanehw