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.

Transcript

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

   View Slide

2. Complexity
   

   View Slide

3. Communicate
   

   View Slide

4. Version Control System
   

   View Slide

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

   View Slide

6. Kept forever
   

   View Slide

7. Always in sync with the code
   

   View Slide

8. Are available to everyone
   

   View Slide

9. Searchable
   

   View Slide

10. $ git log --grep regexp
    

    View Slide

11. SMALL COMMITS
    1
    

    View Slide

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

    View Slide

13. How big or small should a
    commit be?
    

    View Slide

14. $ git add -p
    

    View Slide

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
    

    View Slide

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
    

    View Slide

17. Ref: https://github.com/kristinabrown/dinner-dash/commits/master?page=5
    

    View Slide

18. View Slide

19. $ Fix failed specs
    

    View Slide

20. $ Fix this
    

    View Slide

21. $ Fix stuff
    

    View Slide

22. $ Changed stuff
    

    View Slide

23. $ Testing git push
    

    View Slide

24. $ Adjust css
    

    View Slide

25. $ Bug fix
    

    View Slide

26. $ More work
    

    View Slide

27. $ Minor changes
    

    View Slide

28. $ Work on feature XYZ
    

    View Slide

29. $ Change X constant to be 10
    

    View Slide

30. $ Whoops
    

    View Slide

31. $ Should work now
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

40. SMALL FEATURE BRANCHES
    3
    

    View Slide

41. Encapsulation
    

    View Slide

42. Pull requests
    and code reviews
    

    View Slide

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

    View Slide

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

    View Slide

45. 3. Push changes in the branch to `origin`
    $ git push -u origin em-feature-branch
    or
    $ git push origin head
    

    View Slide

46. 4. Open a PR for feedback
    

    View Slide

47. 5. Implement changes based on feedback
    

    View Slide

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

    View Slide

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

    View Slide

50. 7. Then fast forward merge to master
    $ git checkout master
    $ git merge --ff-only em-feature-branch
    

    View Slide

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
    

    View Slide

52. MERGING VS
    REBASING
    

    View Slide

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

    View Slide

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

    View Slide

55. View Slide

56. Rebasing
    

    View Slide

57. $ git rebase -i origin/master
    

    View Slide

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

    View Slide

59. 
    

    View Slide

60. Rebase 34020519..5eac86e0 onto 34020519 (2 commands)
    Commands:
    p, pick = use commit
    r, reword = use commit, but edit the commit message
    e, edit = use commit, but stop for amending
    s, squash = use commit, but meld into previous commit
    f, fixup = like "squash", but discard this commit's log message
    x, exec = run command (the rest of the line) using shell
    d, drop = remove commit
    l, label = label current HEAD with a name
    t, reset = reset HEAD to a label
    m, merge [-C | -c ] [# ]
    create a merge commit using the original merge commit's
    message (or the oneline, if no original merge commit was
    specified). Use -c 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
    

    View Slide

61. View Slide

62. Auto-squash and xup
    Ref: https://robots.thoughtbot.com/autosquashing-git-commits
    

    View Slide

63. 
    

    View Slide

64. $ git commit --fixup
    $ git rebase --interactive --autosquash master
    

    View Slide

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

    View Slide

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`
    

    View Slide

67. WASH, RINSE, AND REPEAT
    

    View Slide

68. Make small feature-
    speci c commits
    

    View Slide

69. Write good commit
    messages
    

    View Slide

70. Work in small thematic
    feature branches
    

    View Slide

71. Rebase frequently to
    incorporate upstream
    changes
    

    View Slide

72. Review and revise
    history before sharing
    

    View Slide

73. Keep history linear
    

    View Slide

74. Auto-squash commits
    

    View Slide

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

    View Slide