History of a Thriving Codebase

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

57. None
58. None

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