Upgrade to Pro — share decks privately, control downloads, hide ads and more …

History of a Thriving Codebase

45b75f9f866d240362c0d7fa125025ba?s=47 Peter Brown
September 21, 2013

History of a Thriving Codebase

Given at VT Code Camp 2013

45b75f9f866d240362c0d7fa125025ba?s=128

Peter Brown

September 21, 2013
Tweet

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