History of a Thriving Codebase

Given at VT Code Camp 2013

Transcript

1. History of a Thriving Codebase VT Code Camp 2013
2. into the great wide open
3. my inspiration
4. Why version control?
5. collaborate • Work asynchronously • Reduce friction in teams • Github was built around collaboration
6. Communicate • Poor communication causes project failure • Git helps reduce effort to share ideas and build features
7. experiment • Experimentation is part of developer happiness • Git encourages us to experiment via branches
8. gain Confidence • We need to be confident that things will work far into the future • Git allows us to adapt to changing requirements
9. safety net • We make lots of mistakes • Git allows us to gracefully recover
10. What is code history?
11. code History • A series of changes • Story about how the code evolved • Lasts forever • Searchable • Never outdated
12. a series of Changes
13. a series of commits Last Commit
14. a series of commits
15. • SHA (unique identifier) • Snapshot / Set of changes • Description • Date and time • Author • Other details (parents, etc) What is a commit
16. fixing typos
17. refactoring code
18. documentation
19. a new feature
20. Clean history
21. recording history
22. recording history
23. why record history? Learn from the past Adapt to the future
24. but first a story...
25. FFFFFuuuuuuuuuu
26. What is clean history? • Production commits • Every commit has meaning • Every commit adds value • Most commits are complete features, bug fixes, or refactors
27. reducing complexity KISS YAGNI DRY
28. why clean history? • Easier to track down why changes were made • Easier to track down bugs and revert changes • Required in some OSS projects • Easier to backport changes
29. three types of commits • Progress commits • Merge commits • Production commits
30. three types of commits • Progress commits • Merge commits • Production commits History Not History
31. Progress commits • Used to develop a feature • Always in a new branch • Track progress • Short-term safety net • Mutable and not permanent • Ok if tests are failing
32. Merge commits • Represent when a branch is merged • Can be useful • Not required (fast forward merges)
33. Production Commits • Master branch • Tagged (sometimes) • “Immutable” and “permanent” • These are your history • Tests should not be failing
34. crafting a commit message • git commit -v (verbose) • Start with a short summary • Follow with a description of why the commit exists
35. short summary (<= 50 chars) describe “why” (72 column wrap)
36. tools for a clean history
37. branching
38. “we need a feature”
39. “Let’s branch first!”
40. “pick a descriptive name”
41. git branch git branch my_branch git checkout my_branch or... git checkout -b my_branch
42. “now what?”
43. merge, delete, repeat git checkout master git merge my_branch git branch -d my_branch (delete)
44. Branching protips • Always Be Branching • Use a descriptive name • Reduce longevity of branches • Clean up when you’re done • Keep changes to a minimum
45. how do i maintain clean history with branches?
46. Rewriting history
47. ways to rewrite history • Amending commits • Rebasing • Interactive Rebasing • Resetting
48. types of rebasing • git rebase master my_branch • git rebase --onto master br1 br2 • git pull --rebase origin master • git rebase -i origin/master
49. rebasing Master Feature Branch
50. rebasing Master Feature Branch
51. rebasing Feature Branch Master
52. Squashing Commits Master Squashed Commits
53. squashing commits • Understand why you are squashing the commits (is it a single feature, bug fix, etc?) • git fetch (to get master from origin) • git rebase -i origin/master
54. git log --oneline master..convert-hashes
55. git rebase -i origin/master
56. reword & fixup
59. After Before git log --oneline master..convert-hashes
60. rebasing protips • Always fetch before rebasing • Never rebase a branch someone has based work off • Prolong squashing as long as possible • Don’t be discouraged
61. isn’t that dangerous?
62. how does it all fit together?
63. My workflows • Years of changing workflows • Started centralized (subversion style) • Evolved to feature and release focus
64. general workflow • Create branch • Write code and commit it • Open pull request (code review) • Squash commits (if needed) • Merge & tag • Ship it™
65. two types of workflows • Feature branch centric • Release centric
66. feature workflow • Focused on branches for development • Master == Production • Ideal for small projects, early development • Easy to introduce to new teams
67. feature workflow cont. •Branch from master • Write code • Open pull request (code review) •Merge to master • Test in staging environment • Ship it™
68. feature workflow cont. Master
69. feature workflow cont. Master Feature Branch
70. feature workflow cont. Master Feature Branch
71. feature workflow cont. Master
72. release workflow • Also called “gitflow” • Centralized around tagged releases • Ideal for larger projects, enterprise development • More complicated than feature branch workflow
73. release workflow Cont. • Introduces “development” and “release” branches • Branch from development branch • Merge into development branch • Merge development into release • Tag it
74. release workflow cont. courtesy atlassian.com
75. clean history workflow • Every merge/tag has meaning • Every merge/tag adds value • All merges/tags are complete features, bug fixes, or refactors
76. what can we do with a clean history?
77. Search commits
78. Search by message git log -p --grep "wtf"
79. Search by message
80. search by content git log -p -S 'wtf'
81. search by author git log -p --author='beerlington'
82. search by author
83. Search by date git log -p --since=2013-01-01 git log -p --until=2013-09-01 or... Combine them!
84. track down bugs
85. git bisect Broken X
86. git bisect Bad Good ✓ X
87. git bisect Bad Good ? X ✓
88. git bisect Bad Good X ✓
89. git bisect Bad Good X ✓ ?
90. git bisect Bad Good X ✓ X
91. git bisect X X ✓ ✓ ✓ ✓ ✓
92. git bisect • Determine how to verify the bug • Find commit before bug was introduced • Find commit after bug was introduced • git bisect
93. git bisect
94. git bisect
95. git bisect
96. git bisect
97. git bisect protips • Automate with “run” option • The cleaner the history, the easier and faster it is to bisect • git bisect visualize can show where you are in the process
98. who broke the build?
99. who broke the build?
100. How can I fix the code?
101. git blame git blame path/to/file git blame -L start,stop path/to/file
102. git blame
103. github blame
104. Gitk gitk path/to/file
105. git blame protips • Focus on why, not who • Blame doesn’t fix bugs or ship code
106. what if something goes wrong?
107. amending commits
108. a wild typo appears :(
109. git commit --amend
110. reverting commits
111. which commit?
112. git revert xxxxx
113. git revert protips • Always write a good commit message describing why the commit is being reverted. • Better for public commits than rebasing
114. restoring commits
115. git reflog • Records when tip of branches are updated • Reset to, checkout or cherry-pick a commit to recover it
116. git reflog --date=relative Rebase began here
117. my commits! git cherry-pick acb1ffc (individual commits) or git reset --hard af12217 (full recovery)
118. reflog protips • Git periodically purges the reflog • Only available on local system (not distributed) • Commit early and often
119. "Clean history always looks like it was written by someone who cares."
120. Resources https://www.atlassian.com/git/ http://try.github.io http://git-scm.com/docs/gittutorial
121. Thanks! @beerlington beerlington.com