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
まだ間に合う! エンジニアのための生成AIアプリ開発入門 on AWS
minorun365
PRO
4
580
データ基盤の成長を加速させる:アイスタイルにおける挑戦と教訓
tsuda7
3
650
「海外登壇」という 選択肢を与えるために 〜Gophers EX
logica0419
0
500
株式会社EventHub・エンジニア採用資料
eventhub
0
4.2k
室長と気ままに学ぶマイクロソフトのビジネスアプリケーションとビジネスプロセス
ryoheig0405
0
320
Data-centric AI入門第6章:Data-centric AIの実践例
x_ttyszk
1
370
Culture Deck
optfit
0
330
急成長する企業で作った、エンジニアが輝ける制度/ 20250214 Rinto Ikenoue
shift_evolve
2
880
MC906491 を見据えた Microsoft Entra Connect アップグレード対応
tamaiyutaro
1
480
関東Kaggler会LT: 人狼コンペとLLM量子化について
nejumi
3
460
『衛星データ利用の方々にとって近いようで触れる機会のなさそうな小話 ~ 衛星搭載ソフトウェアと衛星運用ソフトウェア (実物) を動かしながらわいわいする編 ~』 @日本衛星データコミニティ勉強会
meltingrabbit
0
120
Moved to https://speakerdeck.com/toshihue/presales-engineer-career-bridging-tech-biz-ja
toshihue
2
550
Featured
See All Featured
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
3
310
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Done Done
chrislema
182
16k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.4k
GraphQLとの向き合い方2022年版
quramy
44
13k
Raft: Consensus for Rubyists
vanstee
137
6.8k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Into the Great Unknown - MozCon
thekraken
35
1.6k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
29
2.2k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Bash Introduction
62gerente
610
210k
Typedesign – Prime Four
hannesfritz
40
2.5k
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