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).

A298fade27a9c2ebe7bea8f93997b5c6?s=128

Emma Jane Hogbin Westby

February 18, 2015
Tweet

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