Story-telling with Git rebase

Story-telling with Git rebase

In a successful software development project, a key challenge is to manage complexity because projects get very complex very quickly even within small teams. Version control is the tool for communicating intent in our codebase over the life time of the project. Rebasing allows us to revise our development history before sharing it with the team. Learn to use Git commit messages to keep track of the intent of your code changes to make it easier to make future changes. Learn how to make using feature branches less painful and more effective. Learn the mechanics of interactive rebasing, how to merge conflicts without losing precious code and how to auto-squash commits. Basically, stop fearing interactive rebasing.

492d339a2ec66fa8d80e937abddb58e6?s=128

Elle Meredith

November 30, 2018
Tweet

Transcript

  1. STORY-TELLING WITH GIT REBASE Elle Meredith @aemeredith Blackmill @blackmillco

  2. Complexity

  3. Communicate

  4. Version Control System

  5. A project’s history is its most valuable documentation Ref: https://mislav.net/2014/02/hidden-documentation/

  6. Kept forever

  7. Always in sync with the code

  8. Are available to everyone

  9. Searchable

  10. $ git log --grep regexp

  11. SMALL COMMITS 1

  12. commit [REDACTED] Date: [REDACTED] - add promotions to custom brand

    bundles - add bundle promotions to custom brands - generate unique custom promo code key - remove validation for nested create - remove binding.pry - update to allow default bundle (no promo) - refactor for empty promotion - tmp precompile assets - refactor dynamic promo code - adding tracking, top/bottom code - removing unused method calls, redundant migration - use scope - style with Rubocop validation - update asset path, fix broken specs - tmp disable integration spec 20 files changed, 349 insertions(+), 129 deletions(-)
  13. How big or small should a commit be?

  14. $ git add -p

  15. Image credit: http://www.artslife.com/2014/09/22/people-places-steve-mccurry-alla-south- bank-tower- no-al-279/ GOOD COMMIT MESSAGES 2

  16. Ref: http://stevetarver.github.io/2016/02/19/intentional-git-comments.html Image credit: https://burst.shopify.com/photos/train-turning-through-fog 1. Clarity of intent 2.

    Clarity of thought 3. Ability to reason about the code
  17. Ref: https://github.com/kristinabrown/dinner-dash/commits/master?page=5

  18. None
  19. $ Fix failed specs

  20. $ Fix this

  21. $ Fix stuff

  22. $ Changed stuff

  23. $ Testing git push

  24. $ Adjust css

  25. $ Bug fix

  26. $ More work

  27. $ Minor changes

  28. $ Work on feature XYZ <x 20 commits>

  29. $ Change X constant to be 10

  30. $ Whoops

  31. $ Should work now

  32. $ WTF? Ref: https://www.codelord.net/2015/03/16/bad-commit-messages-hall-of-shame/

  33. Image credit: https://weheartit.com/entry/104254659

  34. ANSWER 5 QUESTIONS Why is this change necessary? How does

    it address the issue? What side e ects does this change have? Were other solutions considered? Include a reference [to a discussion, resource, ticket ] Ref: https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
  35. Present-tense summary under 50 characters * More information about commit

    (under 72 chars). * More information about commit (under 72 chars). http://project.management-system.com/ticket/123
  36. Present-tense summary under 50 characters * More information about commit

    (under 72 chars). * More information about commit (under 72 chars). http://project.management-system.com/ticket/123
  37. Present-tense summary under 50 characters * More information about commit

    (under 72 chars). * More information about commit (under 72 chars). http://project.management-system.com/ticket/123
  38. commit [REDACTED] Author: Elle Meredith Date: [REDACTED] Add author's name

    to opportunity form - This input field is disabled - so that the user cannot edit the field - It displays the author's name on: - create a new opportunity - edit an existing opportunity - reposting an opportunity - If the author doesn't have a first or last name, display the author's email instead Trello: https://trello.com/c/12345
  39. 1. Add (340 times) 2. Update (339 times) 3. Remove

    / Delete (135 times) 4. Fix (132 times) 5. Use (76 times) 6. Style (56 times) 7. Allow (53 times) 8. Bump (50 times) 9. Show (44 times) 10. Refactor / Clean (35 times) Apply / Change / Con gure / Create / Deprecate / Disable / Display / Drop / Enable / Ensure / Extract / Handle / Improve / Increase / Limit / Link / Make / Migrate / Rename / Set / Skip / Sort / Support / Validate / Wire
  40. SMALL FEATURE BRANCHES 3

  41. Encapsulation

  42. Pull requests and code reviews

  43. 1. Create a new branch $ git checkout -b em-feature-branch

  44. 2. Update the branch, commit new changes $ git status

    $ git add <some-files> $ git commit
  45. 3. Push changes in the branch to `origin` $ git

    push -u origin em-feature-branch or $ git push origin head
  46. 4. Open a PR for feedback

  47. 5. Implement changes based on feedback

  48. 6. Rebase master on the branch interactively and push updated

    branch back up $ git rebase -i master $ git push origin head -f
  49. 6. Rebase master on the branch interactively and push updated

    branch back up $ git rebase -i master $ git push origin head -f
  50. 7. Then fast forward merge to master $ git checkout

    master $ git merge --ff-only em-feature-branch
  51. 8. Lastly clean up the branches $ git push origin

    :em-feature-branch $ git branch -d em-feature-branch Ref: https://github.com/thoughtbot/guides/tree/master/protocol/git
  52. MERGING VS REBASING

  53. $ git merge --no-ff em-feature-branch

  54. Image credit: https://www.atlassian.com/git/tutorials/merging-vs-rebasing

  55. None
  56. Rebasing

  57. $ git rebase -i origin/master

  58. $ git rebase --continue $ git rebase --abort

  59. <coding>

  60. Rebase 34020519..5eac86e0 onto 34020519 (2 commands) Commands: p, pick <commit>

    = use commit r, reword <commit> = use commit, but edit the commit message e, edit <commit> = use commit, but stop for amending s, squash <commit> = use commit, but meld into previous commit f, fixup <commit> = like "squash", but discard this commit's log message x, exec <command> = run command (the rest of the line) using shell d, drop <commit> = remove commit l, label <label> = label current HEAD with a name t, reset <label> = reset HEAD to a label m, merge [-C <commit> | -c <commit>] <label> [# <oneline>] create a merge commit using the original merge commit's message (or the oneline, if no original merge commit was specified). Use -c <commit> to reword the commit message. These lines can be re-ordered;\they are executed from top to bottom. If you remove a line here THAT COMMIT WILL BE LOST. However, if you remove everything, the rebase will be aborted. Note that empty commits are commented out
  61. None
  62. Auto-squash and xup Ref: https://robots.thoughtbot.com/autosquashing-git-commits

  63. <coding>

  64. $ git commit --fixup <sha> $ git rebase --interactive --autosquash

    master
  65. $ git config --global rebase.autosquash true

  66. Rebase often to grab recent updates from `master` Use rebase

    when you want to keep a linear commit history Never use rebase on a public/shared branch- i.e. never rebase `master`
  67. WASH, RINSE, AND REPEAT

  68. Make small feature- speci c commits

  69. Write good commit messages

  70. Work in small thematic feature branches

  71. Rebase frequently to incorporate upstream changes

  72. Review and revise history before sharing

  73. Keep history linear

  74. Auto-squash commits

  75. THANK YOU! Elle Meredith @aemeredith Blackmill @blackmillco Edward watching over

    my sourdough