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
410
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
Extinguish the Fire with Ember.js
beerlington
6
490
Introduction to ClassyEnum and Friends
beerlington
1
250
Lighting Up with Ember.js
beerlington
8
560
Networking Refactored
beerlington
1
100
Intro to Object Oriented Programming in Ruby
beerlington
10
1.1k
Responsible Metaprogramming in Rails
beerlington
3
770
BTVWAG Survey Results
beerlington
1
200
Behavior Driven Development
beerlington
2
930
Other Decks in Technology
See All in Technology
Roo Codeにすべてを委ねるためのルール運用
pharma_x_tech
1
230
ソフトウェアは捨てやすく作ろう/Let's make software easy to discard
sanogemaru
10
5.8k
新卒から4年間、20年もののWebサービスと向き合って学んだソフトウェア考古学 - PHPカンファレンス新潟2025 / new graduate 4year software archeology
oguri
2
350
他チームへ越境したら、生データ提供ソリューションのクエリ費用95%削減へ繋がった話 / Cross-Team Impact: 95% Off Raw Data Query Costs
yamamotoyuta
0
240
TypeScript と歩む OpenAPI の discriminator / OpenAPI discriminator with TypeScript
kaminashi
1
150
セキュリティSaaS企業が実践するCursor運用ルールと知見 / How a Security SaaS Company Runs Cursor: Rules & Insights
tetsuzawa
0
330
金融システムをモダナイズするためのAmazon Elastic Kubernetes Service(EKS)ノウハウ大全
daitak
0
120
データプレーンプログラミングとは? DPU&スイッチASICの開発経験から語る
ebiken
PRO
1
260
プラットフォームとしての Datadog / Datadog as Platforms
aoto
PRO
1
330
2025advance01
minamizaki
0
130
Streamline Cloud-Native App Development Using CDEs
saeedzf
0
850
やさしいClaude Code入門
minorun365
PRO
31
24k
Featured
See All Featured
What's in a price? How to price your products and services
michaelherold
245
12k
How STYLIGHT went responsive
nonsquared
100
5.6k
Docker and Python
trallard
44
3.4k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
750
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
52
2.8k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Mobile First: as difficult as doing things right
swwweet
223
9.6k
The Invisible Side of Design
smashingmag
299
50k
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