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

History of a Thriving Codebase

Peter Brown
September 21, 2013

History of a Thriving Codebase

Given at VT Code Camp 2013

Peter Brown

September 21, 2013
Tweet

More Decks by Peter Brown

Other Decks in Technology

Transcript

  1. History of a
    Thriving Codebase
    VT Code Camp 2013

    View Slide

  2. into the great wide open

    View Slide

  3. my inspiration

    View Slide

  4. Why version control?

    View Slide

  5. collaborate
    • Work asynchronously
    • Reduce friction in teams
    • Github was built around collaboration

    View Slide

  6. Communicate
    • Poor communication causes project
    failure
    • Git helps reduce effort to share ideas
    and build features

    View Slide

  7. experiment
    • Experimentation is part of developer
    happiness
    • Git encourages us to experiment via
    branches

    View Slide

  8. gain Confidence
    • We need to be confident that things
    will work far into the future
    • Git allows us to adapt to changing
    requirements

    View Slide

  9. safety net
    • We make lots of mistakes
    • Git allows us to gracefully recover

    View Slide

  10. What is code history?

    View Slide

  11. code History
    • A series of changes
    • Story about how the code evolved
    • Lasts forever
    • Searchable
    • Never outdated

    View Slide

  12. a series of Changes

    View Slide

  13. a series of commits
    Last Commit

    View Slide

  14. a series of commits

    View Slide

  15. • SHA (unique identifier)
    • Snapshot / Set of changes
    • Description
    • Date and time
    • Author
    • Other details (parents, etc)
    What is a commit

    View Slide

  16. fixing typos

    View Slide

  17. refactoring code

    View Slide

  18. documentation

    View Slide

  19. a new feature

    View Slide

  20. Clean history

    View Slide

  21. recording history

    View Slide

  22. recording history

    View Slide

  23. why record history?
    Learn from the past
    Adapt to the future

    View Slide

  24. but first a story...

    View Slide

  25. FFFFFuuuuuuuuuu

    View Slide

  26. What is clean history?
    • Production commits
    • Every commit has meaning
    • Every commit adds value
    • Most commits are complete features,
    bug fixes, or refactors

    View Slide

  27. reducing complexity
    KISS
    YAGNI
    DRY

    View Slide

  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

    View Slide

  29. three types of commits
    • Progress commits
    • Merge commits
    • Production commits

    View Slide

  30. three types of commits
    • Progress commits
    • Merge commits
    • Production commits
    History
    Not History

    View Slide

  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

    View Slide

  32. Merge commits
    • Represent when a branch is merged
    • Can be useful
    • Not required (fast forward merges)

    View Slide

  33. Production Commits
    • Master branch
    • Tagged (sometimes)
    • “Immutable” and “permanent”
    • These are your history
    • Tests should not be failing

    View Slide

  34. crafting a commit message
    • git commit -v (verbose)
    • Start with a short summary
    • Follow with a description of why the
    commit exists

    View Slide

  35. short summary (<= 50 chars)
    describe “why”
    (72 column wrap)

    View Slide

  36. tools for a clean history

    View Slide

  37. branching

    View Slide

  38. “we need a feature”

    View Slide

  39. “Let’s branch first!”

    View Slide

  40. “pick a descriptive name”

    View Slide

  41. git branch
    git branch my_branch
    git checkout my_branch
    or...
    git checkout -b my_branch

    View Slide

  42. “now what?”

    View Slide

  43. merge, delete, repeat
    git checkout master
    git merge my_branch
    git branch -d my_branch (delete)

    View Slide

  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

    View Slide

  45. how do i maintain clean
    history with branches?

    View Slide

  46. Rewriting history

    View Slide

  47. ways to rewrite history
    • Amending commits
    • Rebasing
    • Interactive Rebasing
    • Resetting

    View Slide

  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

    View Slide

  49. rebasing
    Master
    Feature Branch

    View Slide

  50. rebasing
    Master
    Feature Branch

    View Slide

  51. rebasing
    Feature Branch
    Master

    View Slide

  52. Squashing Commits
    Master
    Squashed Commits

    View Slide

  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

    View Slide

  54. git log --oneline master..convert-hashes

    View Slide

  55. git rebase -i origin/master

    View Slide

  56. reword & fixup

    View Slide

  57. View Slide

  58. View Slide

  59. After Before
    git log --oneline master..convert-hashes

    View Slide

  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

    View Slide

  61. isn’t that dangerous?

    View Slide

  62. how does it all fit
    together?

    View Slide

  63. My workflows
    • Years of changing workflows
    • Started centralized (subversion style)
    • Evolved to feature and release focus

    View Slide

  64. general workflow
    • Create branch
    • Write code and commit it
    • Open pull request (code review)
    • Squash commits (if needed)
    • Merge & tag
    • Ship it™

    View Slide

  65. two types of workflows
    • Feature branch centric
    • Release centric

    View Slide

  66. feature workflow
    • Focused on branches for development
    • Master == Production
    • Ideal for small projects, early
    development
    • Easy to introduce to new teams

    View Slide

  67. feature workflow cont.
    •Branch from master
    • Write code
    • Open pull request (code review)
    •Merge to master
    • Test in staging environment
    • Ship it™

    View Slide

  68. feature workflow cont.
    Master

    View Slide

  69. feature workflow cont.
    Master
    Feature Branch

    View Slide

  70. feature workflow cont.
    Master
    Feature Branch

    View Slide

  71. feature workflow cont.
    Master

    View Slide

  72. release workflow
    • Also called “gitflow”
    • Centralized around tagged releases
    • Ideal for larger projects, enterprise
    development
    • More complicated than feature branch
    workflow

    View Slide

  73. release workflow Cont.
    • Introduces “development” and
    “release” branches
    • Branch from development branch
    • Merge into development branch
    • Merge development into release
    • Tag it

    View Slide

  74. release workflow cont.
    courtesy atlassian.com

    View Slide

  75. clean history workflow
    • Every merge/tag has meaning
    • Every merge/tag adds value
    • All merges/tags are complete
    features, bug fixes, or refactors

    View Slide

  76. what can we do with a
    clean history?

    View Slide

  77. Search commits

    View Slide

  78. Search by message
    git log -p --grep "wtf"

    View Slide

  79. Search by message

    View Slide

  80. search by content
    git log -p -S 'wtf'

    View Slide

  81. search by author
    git log -p --author='beerlington'

    View Slide

  82. search by author

    View Slide

  83. Search by date
    git log -p --since=2013-01-01
    git log -p --until=2013-09-01
    or...
    Combine them!

    View Slide

  84. track down bugs

    View Slide

  85. git bisect
    Broken
    X

    View Slide

  86. git bisect
    Bad
    Good
    ✓ X

    View Slide

  87. git bisect
    Bad
    Good
    ? X

    View Slide

  88. git bisect
    Bad
    Good
    X

    View Slide

  89. git bisect
    Bad
    Good
    X
    ✓ ?

    View Slide

  90. git bisect
    Bad
    Good
    X
    ✓ X

    View Slide

  91. git bisect
    X
    X
    ✓ ✓

    ✓ ✓

    View Slide

  92. git bisect
    • Determine how to verify the bug
    • Find commit before bug was
    introduced
    • Find commit after bug was introduced
    • git bisect

    View Slide

  93. git bisect

    View Slide

  94. git bisect

    View Slide

  95. git bisect

    View Slide

  96. git bisect

    View Slide

  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

    View Slide

  98. who broke the build?

    View Slide

  99. who broke the build?

    View Slide

  100. How can I fix the code?

    View Slide

  101. git blame
    git blame path/to/file
    git blame -L start,stop path/to/file

    View Slide

  102. git blame

    View Slide

  103. github blame

    View Slide

  104. Gitk
    gitk path/to/file

    View Slide

  105. git blame protips
    • Focus on why, not who
    • Blame doesn’t fix bugs or ship code

    View Slide

  106. what if something
    goes wrong?

    View Slide

  107. amending commits

    View Slide

  108. a wild typo appears
    :(

    View Slide

  109. git commit --amend

    View Slide

  110. reverting commits

    View Slide

  111. which commit?

    View Slide

  112. git revert xxxxx

    View Slide

  113. git revert protips
    • Always write a good commit message
    describing why the commit is being
    reverted.
    • Better for public commits than
    rebasing

    View Slide

  114. restoring commits

    View Slide

  115. git reflog
    • Records when tip of branches are
    updated
    • Reset to, checkout or cherry-pick a
    commit to recover it

    View Slide

  116. git reflog --date=relative
    Rebase began here

    View Slide

  117. my commits!
    git cherry-pick acb1ffc (individual commits)
    or
    git reset --hard af12217 (full recovery)

    View Slide

  118. reflog protips
    • Git periodically purges the reflog
    • Only available on local system
    (not distributed)
    • Commit early and often

    View Slide

  119. "Clean history always looks
    like it was written by
    someone who cares."

    View Slide

  120. Resources
    https://www.atlassian.com/git/
    http://try.github.io
    http://git-scm.com/docs/gittutorial

    View Slide

  121. Thanks!
    @beerlington
    beerlington.com

    View Slide