Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
History of a Thriving Codebase
Search
Peter Brown
September 21, 2013
Technology
2
390
History of a Thriving Codebase
Given at VT Code Camp 2013
Peter Brown
September 21, 2013
Tweet
Share
More Decks by Peter Brown
See All by Peter Brown
Make the Internet Great Again with Glimmer.js
beerlington
0
170
Extinguish the Fire with Ember.js
beerlington
6
490
Introduction to ClassyEnum and Friends
beerlington
1
240
Lighting Up with Ember.js
beerlington
8
560
Networking Refactored
beerlington
1
99
Intro to Object Oriented Programming in Ruby
beerlington
10
1k
Responsible Metaprogramming in Rails
beerlington
3
760
BTVWAG Survey Results
beerlington
1
200
Behavior Driven Development
beerlington
2
920
Other Decks in Technology
See All in Technology
データ基盤の成長を加速させる:アイスタイルにおける挑戦と教訓
tsuda7
3
650
Moved to https://speakerdeck.com/toshihue/presales-engineer-career-bridging-tech-biz-ja
toshihue
2
550
日経電子版 x AIエージェントの可能性とAgentic RAGによって提案書生成を行う技術
masahiro_nishimi
1
290
30分でわかる『アジャイルデータモデリング』
hanon52_
9
2.2k
個人開発から公式機能へ: PlaywrightとRailsをつなげた3年の軌跡
yusukeiwaki
10
2.7k
明日からできる!技術的負債の返済を加速するための実践ガイド~『ホットペッパービューティー』の事例をもとに~
recruitengineers
PRO
3
100
自動テストの世界に、この5年間で起きたこと
autifyhq
10
7.1k
家電アプリ共通PF "Linova" のAPI利用とPostman活用事例ご紹介
yukiogawa
0
130
All you need to know about InnoDB Primary Keys
lefred
0
120
Nekko Cloud、 これまでとこれから ~学生サークルが作る、 小さなクラウド
logica0419
2
730
データ資産をシームレスに伝達するためのイベント駆動型アーキテクチャ
kakehashi
PRO
2
230
Platform Engineeringは自由のめまい
nwiizo
4
1.9k
Featured
See All Featured
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
330
21k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
27
1.9k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Building a Scalable Design System with Sketch
lauravandoore
460
33k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
29
4.6k
How to Ace a Technical Interview
jacobian
276
23k
Embracing the Ebb and Flow
colly
84
4.6k
Code Review Best Practice
trishagee
66
17k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
Gamification - CAS2011
davidbonilla
80
5.1k
Code Reviewing Like a Champion
maltzj
521
39k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
8
270
Transcript
History of a Thriving Codebase VT Code Camp 2013
into the great wide open
my inspiration
Why version control?
collaborate • Work asynchronously • Reduce friction in teams •
Github was built around collaboration
Communicate • Poor communication causes project failure • Git helps
reduce effort to share ideas and build features
experiment • Experimentation is part of developer happiness • Git
encourages us to experiment via branches
gain Confidence • We need to be confident that things
will work far into the future • Git allows us to adapt to changing requirements
safety net • We make lots of mistakes • Git
allows us to gracefully recover
What is code history?
code History • A series of changes • Story about
how the code evolved • Lasts forever • Searchable • Never outdated
a series of Changes
a series of commits Last Commit
a series of commits
• SHA (unique identifier) • Snapshot / Set of changes
• Description • Date and time • Author • Other details (parents, etc) What is a commit
fixing typos
refactoring code
documentation
a new feature
Clean history
recording history
recording history
why record history? Learn from the past Adapt to the
future
but first a story...
FFFFFuuuuuuuuuu
What is clean history? • Production commits • Every commit
has meaning • Every commit adds value • Most commits are complete features, bug fixes, or refactors
reducing complexity KISS YAGNI DRY
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
three types of commits • Progress commits • Merge commits
• Production commits
three types of commits • Progress commits • Merge commits
• Production commits History Not History
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
Merge commits • Represent when a branch is merged •
Can be useful • Not required (fast forward merges)
Production Commits • Master branch • Tagged (sometimes) • “Immutable”
and “permanent” • These are your history • Tests should not be failing
crafting a commit message • git commit -v (verbose) •
Start with a short summary • Follow with a description of why the commit exists
short summary (<= 50 chars) describe “why” (72 column wrap)
tools for a clean history
branching
“we need a feature”
“Let’s branch first!”
“pick a descriptive name”
git branch git branch my_branch git checkout my_branch or... git
checkout -b my_branch
“now what?”
merge, delete, repeat git checkout master git merge my_branch git
branch -d my_branch (delete)
Branching protips • Always Be Branching • Use a descriptive
name • Reduce longevity of branches • Clean up when you’re done • Keep changes to a minimum
how do i maintain clean history with branches?
Rewriting history
ways to rewrite history • Amending commits • Rebasing •
Interactive Rebasing • Resetting
types of rebasing • git rebase master my_branch • git
rebase --onto master br1 br2 • git pull --rebase origin master • git rebase -i origin/master
rebasing Master Feature Branch
rebasing Master Feature Branch
rebasing Feature Branch Master
Squashing Commits Master Squashed Commits
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
git log --oneline master..convert-hashes
git rebase -i origin/master
reword & fixup
None
None
After Before git log --oneline master..convert-hashes
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
isn’t that dangerous?
how does it all fit together?
My workflows • Years of changing workflows • Started centralized
(subversion style) • Evolved to feature and release focus
general workflow • Create branch • Write code and commit
it • Open pull request (code review) • Squash commits (if needed) • Merge & tag • Ship it™
two types of workflows • Feature branch centric • Release
centric
feature workflow • Focused on branches for development • Master
== Production • Ideal for small projects, early development • Easy to introduce to new teams
feature workflow cont. •Branch from master • Write code •
Open pull request (code review) •Merge to master • Test in staging environment • Ship it™
feature workflow cont. Master
feature workflow cont. Master Feature Branch
feature workflow cont. Master Feature Branch
feature workflow cont. Master
release workflow • Also called “gitflow” • Centralized around tagged
releases • Ideal for larger projects, enterprise development • More complicated than feature branch workflow
release workflow Cont. • Introduces “development” and “release” branches •
Branch from development branch • Merge into development branch • Merge development into release • Tag it
release workflow cont. courtesy atlassian.com
clean history workflow • Every merge/tag has meaning • Every
merge/tag adds value • All merges/tags are complete features, bug fixes, or refactors
what can we do with a clean history?
Search commits
Search by message git log -p --grep "wtf"
Search by message
search by content git log -p -S 'wtf'
search by author git log -p --author='beerlington'
search by author
Search by date git log -p --since=2013-01-01 git log -p
--until=2013-09-01 or... Combine them!
track down bugs
git bisect Broken X
git bisect Bad Good ✓ X
git bisect Bad Good ? X ✓
git bisect Bad Good X ✓
git bisect Bad Good X ✓ ?
git bisect Bad Good X ✓ X
git bisect X X ✓ ✓ ✓ ✓ ✓
git bisect • Determine how to verify the bug •
Find commit before bug was introduced • Find commit after bug was introduced • git bisect
git bisect
git bisect
git bisect
git bisect
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
who broke the build?
who broke the build?
How can I fix the code?
git blame git blame path/to/file git blame -L start,stop path/to/file
git blame
github blame
Gitk gitk path/to/file
git blame protips • Focus on why, not who •
Blame doesn’t fix bugs or ship code
what if something goes wrong?
amending commits
a wild typo appears :(
git commit --amend
reverting commits
which commit?
git revert xxxxx
git revert protips • Always write a good commit message
describing why the commit is being reverted. • Better for public commits than rebasing
restoring commits
git reflog • Records when tip of branches are updated
• Reset to, checkout or cherry-pick a commit to recover it
git reflog --date=relative Rebase began here
my commits! git cherry-pick acb1ffc (individual commits) or git reset
--hard af12217 (full recovery)
reflog protips • Git periodically purges the reflog • Only
available on local system (not distributed) • Commit early and often
"Clean history always looks like it was written by someone
who cares."
Resources https://www.atlassian.com/git/ http://try.github.io http://git-scm.com/docs/gittutorial
Thanks! @beerlington beerlington.com