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. Communicate • Poor communication causes project failure • Git helps

    reduce effort to share ideas and build features
  2. gain Confidence • We need to be confident that things

    will work far into the future • Git allows us to adapt to changing requirements
  3. safety net • We make lots of mistakes • Git

    allows us to gracefully recover
  4. code History • A series of changes • Story about

    how the code evolved • Lasts forever • Searchable • Never outdated
  5. • SHA (unique identifier) • Snapshot / Set of changes

    • Description • Date and time • Author • Other details (parents, etc) What is a commit
  6. What is clean history? • Production commits • Every commit

    has meaning • Every commit adds value • Most commits are complete features, bug fixes, or refactors
  7. 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
  8. three types of commits • Progress commits • Merge commits

    • Production commits History Not History
  9. 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
  10. Merge commits • Represent when a branch is merged •

    Can be useful • Not required (fast forward merges)
  11. Production Commits • Master branch • Tagged (sometimes) • “Immutable”

    and “permanent” • These are your history • Tests should not be failing
  12. crafting a commit message • git commit -v (verbose) •

    Start with a short summary • Follow with a description of why the commit exists
  13. Branching protips • Always Be Branching • Use a descriptive

    name • Reduce longevity of branches • Clean up when you’re done • Keep changes to a minimum
  14. types of rebasing • git rebase master my_branch • git

    rebase --onto master br1 br2 • git pull --rebase origin master • git rebase -i origin/master
  15. 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
  16. 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
  17. My workflows • Years of changing workflows • Started centralized

    (subversion style) • Evolved to feature and release focus
  18. general workflow • Create branch • Write code and commit

    it • Open pull request (code review) • Squash commits (if needed) • Merge & tag • Ship it™
  19. feature workflow • Focused on branches for development • Master

    == Production • Ideal for small projects, early development • Easy to introduce to new teams
  20. feature workflow cont. •Branch from master • Write code •

    Open pull request (code review) •Merge to master • Test in staging environment • Ship it™
  21. release workflow • Also called “gitflow” • Centralized around tagged

    releases • Ideal for larger projects, enterprise development • More complicated than feature branch workflow
  22. release workflow Cont. • Introduces “development” and “release” branches •

    Branch from development branch • Merge into development branch • Merge development into release • Tag it
  23. clean history workflow • Every merge/tag has meaning • Every

    merge/tag adds value • All merges/tags are complete features, bug fixes, or refactors
  24. Search by date git log -p --since=2013-01-01 git log -p

    --until=2013-09-01 or... Combine them!
  25. git bisect • Determine how to verify the bug •

    Find commit before bug was introduced • Find commit after bug was introduced • git bisect
  26. 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
  27. git blame protips • Focus on why, not who •

    Blame doesn’t fix bugs or ship code
  28. git revert protips • Always write a good commit message

    describing why the commit is being reverted. • Better for public commits than rebasing
  29. git reflog • Records when tip of branches are updated

    • Reset to, checkout or cherry-pick a commit to recover it
  30. reflog protips • Git periodically purges the reflog • Only

    available on local system (not distributed) • Commit early and often