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
Branching - Getting It Right for Us
Search
Luke van der Hoeven
August 30, 2013
Programming
2
44
Branching - Getting It Right for Us
Sometimes the way you do it is not the way we do it...
Luke van der Hoeven
August 30, 2013
Tweet
Share
More Decks by Luke van der Hoeven
See All by Luke van der Hoeven
TrainWreck: Architecture
plukevdh
1
58
Other Decks in Programming
See All in Programming
フロントエンドのパフォーマンスチューニング
koukimiura
6
2.3k
AIに安心して任せるためにTypeScriptで一意な型を作ろう
arfes0e2b3c
0
310
なぜあなたのオブザーバビリティ導入は頓挫するのか
ryota_hnk
4
540
No Install CMS戦略 〜 5年先を見据えたフロントエンド開発を考える / no_install_cms
rdlabo
0
410
DynamoDBは怖くない!〜テーブル設計の勘所とテスト戦略〜
hyamazaki
0
120
バイブコーディング超えてバイブデプロイ〜CloudflareMCPで実現する、未来のアプリケーションデリバリー〜
azukiazusa1
3
760
코딩 에이전트 체크리스트: Claude Code ver.
nacyot
0
1k
대규모 트래픽을 처리하는 프론트 개발자의 전략
maryang
0
110
テスターからテストエンジニアへ ~新米テストエンジニアが歩んだ9ヶ月振り返り~
non0113
2
250
PHPUnitの限界をPlaywrightで補完するテストアプローチ
yuzneri
0
360
中級グラフィックス入門~効率的なメッシュレット描画~
projectasura
4
2.1k
MCP連携で加速するAI駆動開発/mcp integration accelerates ai-driven-development
bpstudy
0
210
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
223
9.8k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Language of Interfaces
destraynor
158
25k
Code Reviewing Like a Champion
maltzj
524
40k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Unsuck your backbone
ammeep
671
58k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
110
19k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
How to Think Like a Performance Engineer
csswizardry
25
1.8k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
KATA
mclloyd
31
14k
Transcript
Branching Getting It Right...
...for us
We’ve Been Here Before Now we know what we’re doing...
...maybe
The Hybrid Model
• Master Integration • Feature • Release Assembly Three Types
of Branches
• Contains only released code • Always releasable (continuous deployment)
• No active work ongoing What Is: Master
• Active, in-progress work • New code is always done
in a feature branch • Contains an independent, fully-functional feature What Is: Feature
• Contains code being prepared for release • Made up
of merges from feature branches • No active work ongoing. What Is: Release
A Generic Scenario
None
Another day, another promotion
None
Break Them Up
None
Work Progresses and Time Passes
None
Time to Think QA and Releases
None
What’s Going On • QA starts testing the release •
Developers are working on the feature branches • Life is good...
When suddenly, QA finds a BUG as they often do
If the bug is with Feature A, where does the
fix go? QA starts testing here, finds bug...
fixed here
QA resumes testing here Merge feature branch to release branch
again
Good thing we branched.
None
None
And finally, it’s ready for release!
After the release is done, code is shipped, everyone is
happy...
None
But wait, someone decided to kill Feature B two days
before release! WHAT DO WE DO?
We burn the office to the ground.
Not an option?
Good thing we branched.
None
Delete the release branch!
Create a new release branch! QA resumes testing with new
release
That was easy.
Good thing we branched.
None
Oh snap, we need to start on the next release
RIGHT NOW
None
Good thing we branched.
None
got the theme yet?
The Rules • All work is done in feature branches
• All release branches must be branched from master • Master contains only released code
An Important Note • Merge direction is critical to keeping
code isolated • Releases only merge down to master or from features. • Features only merge up from master
Note the direction of the dotted lines
Any Last Thoughts?
I’m glad you asked
Use GIT