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