1
00:00:00,040 --> 00:00:02,480
Welcome to the deep dive. 
Today we're getting into 

2
00:00:02,480 --> 00:00:05,560
something really core to 
software development, how teams 

3
00:00:05,560 --> 00:00:08,880
actually manage their code 
day-to-day, specifically 

4
00:00:08,960 --> 00:00:11,240
branching. 
Yeah, we're digging into some 

5
00:00:11,240 --> 00:00:14,960
great material here from Marco 
Tulio Valenti's book Software 

6
00:00:14,960 --> 00:00:19,040
Engineering a Modern Approach, 
focusing on Chapter 13. 

7
00:00:19,040 --> 00:00:21,600
Our goal? 
To really breakdown the three 

8
00:00:21,840 --> 00:00:24,720
big branching strategies you 
hear about all the time. 

9
00:00:25,040 --> 00:00:29,040
Get Flow, GitHub Flow and Trunk 
Based Development or TBD give 

10
00:00:29,040 --> 00:00:31,680
you a quick way to grasp them. 
And it really matters, you know,

11
00:00:31,680 --> 00:00:33,720
choosing the right strategy. 
It's not just a technical 

12
00:00:33,720 --> 00:00:35,760
footnote. 
It shapes how fast you integrate

13
00:00:35,760 --> 00:00:39,200
changes, how often you run into 
those awful merge conflicts and,

14
00:00:39,440 --> 00:00:41,160
well, ultimately the quality you
ship. 

15
00:00:41,160 --> 00:00:44,320
We're aiming for that aha moment
for you, figuring out which fits

16
00:00:44,320 --> 00:00:45,360
where. 
Exactly. 

17
00:00:45,360 --> 00:00:48,280
It's all about the trade-offs. 
OK, let's unpack, starting with 

18
00:00:48,280 --> 00:00:50,320
I guess the most established 
one, right? 

19
00:00:50,320 --> 00:00:52,400
Get flow. 
This one goes back to Vincent 

20
00:00:52,400 --> 00:00:56,560
Dreisen 2010. 
I think For ages this was the 

21
00:00:56,560 --> 00:00:57,480
way. 
It's definitely the most 

22
00:00:57,480 --> 00:00:59,640
structured. 
Lots of moving parts, 2 

23
00:00:59,640 --> 00:01:01,360
permanent branches, 3 temporary 
ones. 

24
00:01:01,360 --> 00:01:03,800
It's got a whole system. 
It really does. 

25
00:01:03,800 --> 00:01:08,360
Think of it like having 2 main 
arteries. 

26
00:01:08,600 --> 00:01:09,720
Those are the permanent 
branches. 

27
00:01:09,720 --> 00:01:12,640
First, there's main, sometimes 
called master or trunk 

28
00:01:12,640 --> 00:01:14,440
historically, but Maine is 
common now. 

29
00:01:14,840 --> 00:01:18,040
This holds only code that's 
absolutely ready for production 

30
00:01:18,280 --> 00:01:19,800
stuff you could deploy right 
now. 

31
00:01:20,160 --> 00:01:23,200
OK. 
So Maine is the pristine ready 

32
00:01:23,200 --> 00:01:25,760
to go version. 
What's the second permanent one 

33
00:01:25,760 --> 00:01:27,400
that that's where the active 
work happens? 

34
00:01:27,480 --> 00:01:29,360
That's it exactly. 
That's the developed branch. 

35
00:01:29,360 --> 00:01:32,320
So if Maine is the finished 
product on the shelf, Develop is

36
00:01:32,320 --> 00:01:35,320
kind of like the workshop floor.
It collects all the features 

37
00:01:35,320 --> 00:01:38,000
developers have finished, but 
before they've gone through, 

38
00:01:38,000 --> 00:01:40,040
say, final QA testing. 
Ah. 

39
00:01:40,800 --> 00:01:44,360
OK, so it assumes that testing 
phase often with a separate QA 

40
00:01:44,360 --> 00:01:45,720
team maybe? 
Often, yeah. 

41
00:01:45,840 --> 00:01:48,040
It reflects that more 
traditional pipeline where 

42
00:01:48,040 --> 00:01:51,240
development hands off to QA. 
Now the temporary branches are 

43
00:01:51,240 --> 00:01:54,240
where the real action is how 
code moves between develop and 

44
00:01:54,240 --> 00:01:55,600
main. 
Let's break those down. 

45
00:01:55,600 --> 00:01:56,880
First up, feature branches, 
right? 

46
00:01:56,880 --> 00:01:58,400
Correct. 
A developer wants to build 

47
00:01:58,400 --> 00:02:00,120
something new. 
They branch off, develop, they 

48
00:02:00,120 --> 00:02:01,600
do their work, commit, commit, 
commit. 

49
00:02:01,800 --> 00:02:03,240
Well, locally maybe they're 
pushed. 

50
00:02:03,560 --> 00:02:06,000
It could be local sometimes 
Valenti mentions that, but 

51
00:02:06,000 --> 00:02:07,720
usually push so others can see 
it. 

52
00:02:08,039 --> 00:02:11,039
Once the feature is done, they 
merge it back into develop and 

53
00:02:11,039 --> 00:02:14,480
then poof, the feature branch is
deleted, kept tidy. 

54
00:02:14,760 --> 00:02:17,000
OK, feature to develop. 
What's next? 

55
00:02:17,080 --> 00:02:20,240
How does stuff get ready for 
like a release? 

56
00:02:20,640 --> 00:02:22,760
That brings us to release 
branches. 

57
00:02:22,840 --> 00:02:26,240
So the team looks at develop and
says, OK, we've got enough good 

58
00:02:26,240 --> 00:02:28,760
stuff here for version 2, point 
O, they cut a release branch 

59
00:02:28,760 --> 00:02:31,320
from develop. 
This branch is then specifically

60
00:02:31,320 --> 00:02:34,880
for stabilization. 
Think bug fixing, final tweets, 

61
00:02:35,120 --> 00:02:38,240
documentation updates, getting 
it ready for prime time. 

62
00:02:38,400 --> 00:02:41,240
This is often where that 
dedicated QA team really hammers

63
00:02:41,240 --> 00:02:43,080
on. 
It right hardening it and when 

64
00:02:43,080 --> 00:02:46,360
that release branch is finally 
approved, maybe by the customer 

65
00:02:46,360 --> 00:02:48,920
or product owner, it doesn't 
just go to Maine, does it? 

66
00:02:48,920 --> 00:02:50,360
It goes two ways. 
Exactly. 

67
00:02:50,360 --> 00:02:52,680
That's a key part of get flows 
structure. 

68
00:02:52,800 --> 00:02:55,080
Once it gets the thumbs up, it's
merged into Maine. 

69
00:02:55,080 --> 00:02:58,160
That's your actual deployment 
trigger, and crucially, it's 

70
00:02:58,160 --> 00:03:00,440
also merged back into develop. 
Right back to develop. 

71
00:03:00,520 --> 00:03:03,920
Well, imagine you found a few 
small bugs during that final QA 

72
00:03:03,920 --> 00:03:05,880
on the release branch and fixed 
them there. 

73
00:03:06,520 --> 00:03:09,240
You need those fixes back and 
develop so they're not lost and 

74
00:03:09,240 --> 00:03:11,880
are part of the baseline for the
next round of features. 

75
00:03:12,320 --> 00:03:14,120
Keeps everything in the sync. 
Makes sense. 

76
00:03:14,440 --> 00:03:18,680
Okay, one more temporary branch.
What about emergencies like a 

77
00:03:18,680 --> 00:03:20,120
critical bug hits production 
right now? 

78
00:03:20,360 --> 00:03:22,080
Yep, got to have an escape 
hatch. 

79
00:03:22,080 --> 00:03:25,200
That's the hot fix branch. 
This is the dedicated path for 

80
00:03:25,200 --> 00:03:27,520
those all hands on deck 
production fires. 

81
00:03:27,880 --> 00:03:30,400
If there's a critical issue on 
Main, you branch a hot fix 

82
00:03:30,400 --> 00:03:32,600
directly from Maine. 
Not from develop. 

83
00:03:32,600 --> 00:03:35,040
No, straight from Maine. 
You put the fix commits onto 

84
00:03:35,040 --> 00:03:37,560
that hot fix branch. 
Then just like the release 

85
00:03:37,560 --> 00:03:41,760
branch, it merges back two ways 
into Maine, often getting tagged

86
00:03:41,760 --> 00:03:45,040
immediately like version 1.0 
point 1 and also back into 

87
00:03:45,040 --> 00:03:47,240
develop so the fix isn't lost 
for future work. 

88
00:03:47,480 --> 00:03:49,280
Wow. 
OK, so the full picture is 

89
00:03:49,520 --> 00:03:52,480
future branches feed develop, 
develop gets bundled into 

90
00:03:53,320 --> 00:03:55,800
release branches, release 
branches get approved and feed 

91
00:03:55,800 --> 00:03:58,320
both main and develop, and 
hotfixes jump straight from 

92
00:03:58,320 --> 00:04:01,440
Maine to fix emergencies, then 
update both main and develop. 

93
00:04:01,520 --> 00:04:03,360
You got it. 
It's very methodical. 

94
00:04:03,600 --> 00:04:08,000
It sounds incredibly safe, very 
structured, ideal for situations

95
00:04:08,000 --> 00:04:11,080
where you have maybe strict 
regulations or mandatory 

96
00:04:11,080 --> 00:04:13,200
customer sign offs before 
anything goes live. 

97
00:04:13,480 --> 00:04:16,200
Places where that multi stage 
process is necessary. 

98
00:04:16,240 --> 00:04:18,920
Definitely safety and 
predictability are the big wins.

99
00:04:19,000 --> 00:04:22,760
But, and this is a big but, that
very structure can cause its own

100
00:04:22,760 --> 00:04:25,840
problems and slow things. 
Down here's where it gets really

101
00:04:25,840 --> 00:04:28,320
interesting. 
The downsides you mentioned 

102
00:04:28,320 --> 00:04:30,560
bottlenecks. 
Developers often talk about 

103
00:04:30,680 --> 00:04:34,040
merge hell with git flow. 
What's that actually feel like 

104
00:04:34,040 --> 00:04:36,680
for a team if my feature branch 
takes weeks to finish? 

105
00:04:37,080 --> 00:04:41,160
It's painful. 
Technically it means if I branch

106
00:04:41,160 --> 00:04:44,480
off, develop and then develop, 
it's getting new features merged

107
00:04:44,480 --> 00:04:47,200
into it while I'm working away 
for 2-3 weeks, by the time I try

108
00:04:47,200 --> 00:04:49,320
to merge my branch back in 
disaster. 

109
00:04:49,320 --> 00:04:51,880
Conflicts everywhere. 
Exactly Dozens, maybe hundreds 

110
00:04:51,880 --> 00:04:54,040
of conflicts. 
My code doesn't fit neatly 

111
00:04:54,040 --> 00:04:57,320
anymore, so instead of shipping 
my feature, I'm spending hours, 

112
00:04:57,320 --> 00:05:00,920
maybe days, just trying to 
untangle the mess, figuring out 

113
00:05:00,920 --> 00:05:04,160
who's change should win. 
It's incredibly frustrating and 

114
00:05:04,160 --> 00:05:06,680
kills velocity. 
So the elaborate branching 

115
00:05:06,920 --> 00:05:10,800
designed for safety ironically 
creates huge integration 

116
00:05:10,800 --> 00:05:14,000
friction, and that feedback loop
must be slow too, right? 

117
00:05:14,200 --> 00:05:16,680
I finished my code, but I don't 
really know if it works in the 

118
00:05:16,680 --> 00:05:19,520
bigger picture until much later 
when it finally hits a release 

119
00:05:19,520 --> 00:05:22,640
branch and gets tested properly.
That's the other major drawback.

120
00:05:22,640 --> 00:05:25,640
Delayed feedback. 
You push your code, it goes into

121
00:05:25,640 --> 00:05:28,800
develop, but it might sit there 
for weeks before it's part of a 

122
00:05:28,800 --> 00:05:30,640
release candidate that gets real
scrutiny. 

123
00:05:30,640 --> 00:05:34,520
It slows down learning, slows 
down iteration if the cost of 

124
00:05:34,520 --> 00:05:38,440
structure is constant, merge 
pain and slow feedback, well, 

125
00:05:38,440 --> 00:05:40,240
people started looking for 
something simpler. 

126
00:05:40,360 --> 00:05:42,600
Which leads us nicely to GitHub 
Flow. 

127
00:05:42,960 --> 00:05:47,360
If git flow is the complex 5 
branch beast, GitHub flow is 

128
00:05:47,360 --> 00:05:50,760
like the minimalist response, 
way simpler. 

129
00:05:50,800 --> 00:05:52,560
Basically just main and feature 
branches, right? 

130
00:05:52,560 --> 00:05:56,000
They ditch develop, release, 
hotfix, all of that. 

131
00:05:56,000 --> 00:05:57,800
Pretty much, yeah. 
It streamlines things 

132
00:05:57,800 --> 00:06:00,520
dramatically, but the real 
innovation isn't just fewer 

133
00:06:00,520 --> 00:06:02,960
branches, it's about when the 
quality checks happen. 

134
00:06:03,160 --> 00:06:06,200
GitHub Flow builds the review 
process right into the workflow 

135
00:06:06,200 --> 00:06:08,760
before anything hits the main 
line, usually using pull 

136
00:06:08,760 --> 00:06:11,280
requests or PRS. 
The pull request. 

137
00:06:11,280 --> 00:06:13,760
That's the key mechanism here. 
Absolutely. 

138
00:06:13,760 --> 00:06:16,080
It's designed around the kind of
features you get in platforms 

139
00:06:16,080 --> 00:06:18,240
like GitHub or GitLab or 
Bitbucket. 

140
00:06:18,640 --> 00:06:22,480
The PR is the focal point for 
discussion and approval. 

141
00:06:22,920 --> 00:06:26,880
So walk us through the steps for
a developer using GitHub Flow. 

142
00:06:26,880 --> 00:06:30,200
It sounds much more linear. 
It is super straightforward. 

143
00:06:30,200 --> 00:06:33,840
One, create a local branch for 
your feature or fix, give it a 

144
00:06:33,840 --> 00:06:40,160
clear name. 2 Do the work, write
the code, commit often. 3 Push 

145
00:06:40,160 --> 00:06:42,480
that branch up to the remote 
server, like GitHub. 

146
00:06:42,680 --> 00:06:46,400
OK, code is push now what? 
4 you open a pull request. 

147
00:06:46,400 --> 00:06:49,320
This is basically you saying hey
team I've got this code it does 

148
00:06:49,320 --> 00:06:51,640
X can someone please review it 
before we merge it? 

149
00:06:51,720 --> 00:06:53,320
Right, it's a formal request for
scrutiny. 

150
00:06:53,320 --> 00:06:54,840
Exactly. 
Then Step 5. 

151
00:06:55,280 --> 00:06:57,960
Someone else, a teammate, a 
lead, maybe even automated 

152
00:06:57,960 --> 00:07:00,160
checks kick in, reviews the code
in the PR. 

153
00:07:00,160 --> 00:07:02,000
They might ask for changes, 
discuss things. 

154
00:07:02,640 --> 00:07:05,640
Once everyone's happy and it's 
approved, then the code gets 

155
00:07:05,640 --> 00:07:07,600
merged directly into the main 
branch. 

156
00:07:07,640 --> 00:07:10,840
Directly into Maine, so Maine is
always potentially deployable. 

157
00:07:10,840 --> 00:07:14,200
That's the idea. 
As soon as a PR is merged, Maine

158
00:07:14,200 --> 00:07:15,280
should be in a state where you 
could. 

159
00:07:15,280 --> 00:07:17,360
Deploy it. 
Much faster cycle time 

160
00:07:17,440 --> 00:07:20,080
potentially. 
Who's this best suited for? 

161
00:07:20,680 --> 00:07:24,160
It's really common for web 
application systems where you 

162
00:07:24,160 --> 00:07:27,400
generally only have one main 
version in production at a time.

163
00:07:27,760 --> 00:07:30,840
You want to get changes reviewed
and integrated into that 

164
00:07:30,840 --> 00:07:34,280
deployable main branch quickly, 
without the ceremony of 

165
00:07:34,280 --> 00:07:37,000
gitflow's release branches. 
OK, but every system has 

166
00:07:37,000 --> 00:07:40,120
trade-offs. 
Gitflow's bottleneck was merge 

167
00:07:40,120 --> 00:07:41,920
conflicts from long lived 
branches. 

168
00:07:42,560 --> 00:07:44,800
Where is the potential slowdown 
in GitHub flow? 

169
00:07:45,160 --> 00:07:46,600
It sounds like the review 
itself. 

170
00:07:46,600 --> 00:07:48,160
That's generally the main 
challenge, yeah. 

171
00:07:48,320 --> 00:07:51,000
The PR review process can become
the new bottleneck. 

172
00:07:51,280 --> 00:07:54,280
If your reviewers are swamped, 
or if the team culture doesn't 

173
00:07:54,280 --> 00:07:57,120
prioritize quick reviews, your 
code might sit waiting for 

174
00:07:57,120 --> 00:07:59,920
approval for days. 
So you've just shifted the delay

175
00:07:59,920 --> 00:08:02,480
from complex merges to human 
review cycles. 

176
00:08:02,960 --> 00:08:05,400
In essence, yes. 
It solves one problem, but can 

177
00:08:05,400 --> 00:08:07,280
introduce another if not managed
well. 

178
00:08:07,480 --> 00:08:10,280
It requires A-Team culture that 
values fast, high quality 

179
00:08:10,280 --> 00:08:12,720
reviews. 
OK, so if git flow is structure 

180
00:08:13,000 --> 00:08:16,080
and GitHub flow is review 
centric, there's one more model 

181
00:08:16,080 --> 00:08:19,280
that takes simplicity and speed 
to the absolute extreme. 

182
00:08:19,760 --> 00:08:24,280
Trunk based development TBD. 
This sounds like the simplest on

183
00:08:24,280 --> 00:08:26,760
paper. 
Just one branch main. 

184
00:08:26,960 --> 00:08:28,240
That's it. 
That's basically it. 

185
00:08:28,240 --> 00:08:32,080
TBD is all about keeping 
everyone working directly on or 

186
00:08:32,080 --> 00:08:34,000
very close to the main line, the
trunk. 

187
00:08:34,520 --> 00:08:37,760
It's less a specific set of 
branch rules and more a 

188
00:08:37,880 --> 00:08:39,880
philosophy of continuous 
integration. 

189
00:08:40,200 --> 00:08:42,520
Think high frequency commits 
directly to Maine. 

190
00:08:42,520 --> 00:08:44,800
Multiple times a day even. 
Ideally, yes. 

191
00:08:44,960 --> 00:08:47,600
It's the kind of approach used 
by places known for moving 

192
00:08:47,600 --> 00:08:50,200
incredibly fast. 
Like, you know, Google or Amazon

193
00:08:50,200 --> 00:08:53,000
are often cited examples. 
Small changes integrated. 

194
00:08:53,640 --> 00:08:56,840
OK, but wait, if everyone's 
merging straight into Maine all 

195
00:08:56,840 --> 00:08:59,520
the time, doesn't that sound 
incredibly risky? 

196
00:08:59,720 --> 00:09:02,000
How do you avoid breaking the 
build constantly? 

197
00:09:02,000 --> 00:09:04,000
Can developers still use feature
branches at all? 

198
00:09:04,040 --> 00:09:06,760
They can, but here's the catch. 
And Valente is really clear on 

199
00:09:06,760 --> 00:09:09,200
this. 
If you do use a branch in PBD, 

200
00:09:09,200 --> 00:09:10,920
it has to be extremely short 
lived. 

201
00:09:10,960 --> 00:09:13,880
The rule of thumb often quoted 
is no more than two days. 

202
00:09:13,880 --> 00:09:15,080
Max two days? 
What? 

203
00:09:15,080 --> 00:09:16,600
2 days? 
What's magical about that 

204
00:09:16,600 --> 00:09:18,760
number? 
It's not magic, but it 

205
00:09:18,760 --> 00:09:21,520
represents A threshold. 
If your branch lives longer than

206
00:09:21,520 --> 00:09:24,400
a couple of days, it starts to 
drift significantly from the 

207
00:09:24,400 --> 00:09:27,520
main trunk, which is evolving 
rapidly because everyone else is

208
00:09:27,520 --> 00:09:30,280
merging into it constantly. 
Ah, so a three day branch is 

209
00:09:30,280 --> 00:09:32,800
already becoming a a long lived 
feature branch. 

210
00:09:32,800 --> 00:09:35,600
Exactly, and that's the 
antithesis of TBD. 

211
00:09:36,120 --> 00:09:39,520
As soon as you have long lived 
branches, you reintroduce the 

212
00:09:39,520 --> 00:09:43,520
risk of those massive, painful 
merge conflicts that TBD is 

213
00:09:43,520 --> 00:09:47,280
specifically designed to avoid. 
The whole point is small, 

214
00:09:47,280 --> 00:09:50,280
frequent, easy integrations. 
OK, so this demands extreme 

215
00:09:50,280 --> 00:09:52,760
discipline. 
If every merge is potentially 

216
00:09:52,760 --> 00:09:56,200
one step away from production, 
you absolutely cannot afford to 

217
00:09:56,200 --> 00:09:58,200
break things. 
This sounds like automation 

218
00:09:58,200 --> 00:10:01,720
doesn't just nice to have 
anymore, it's mandatory. 100% 

219
00:10:01,720 --> 00:10:03,720
mandatory. 
You cannot do TBD effectively 

220
00:10:03,720 --> 00:10:06,800
without a rock solid 
comprehensive suite of automated

221
00:10:06,800 --> 00:10:10,400
tests, unit tests, integration 
tests, maybe even end to end 

222
00:10:10,400 --> 00:10:12,480
tests. 
These tests have to run 

223
00:10:12,480 --> 00:10:15,360
automatically on every single 
proposed change before it gets 

224
00:10:15,360 --> 00:10:17,720
merged into main. 
They are your safety net. 

225
00:10:17,760 --> 00:10:20,440
Because there's no QA team 
waiting downstream like in Get 

226
00:10:20,440 --> 00:10:21,280
Flow. 
Right. 

227
00:10:21,520 --> 00:10:24,160
The automation is the primary QA
gate. 

228
00:10:24,600 --> 00:10:28,880
This naturally leads teams doing
TBD to embrace continuous 

229
00:10:28,880 --> 00:10:32,080
integration or CI very heavily. 
That's the practice of 

230
00:10:32,240 --> 00:10:35,640
automatically building and 
testing every change, and often 

231
00:10:35,760 --> 00:10:39,080
continuous deployment CD 
automatically deploying changes 

232
00:10:39,080 --> 00:10:42,400
that pass all the tests. 
So TBD and CICD are basically 

233
00:10:42,400 --> 00:10:44,240
two sides of the same coin. 
Very much so. 

234
00:10:44,400 --> 00:10:48,960
TBD is the development practice 
that makes true high frequency 

235
00:10:48,960 --> 00:10:51,840
CICD feasible. 
But what about bigger features? 

236
00:10:51,840 --> 00:10:54,920
Things that realistically take, 
say, A-Team several weeks to 

237
00:10:54,920 --> 00:10:56,600
build? 
You can't do that in two day 

238
00:10:56,600 --> 00:10:59,240
branches. 
How does TBD handle large 

239
00:10:59,240 --> 00:11:00,880
initiatives? 
Great question. 

240
00:11:00,880 --> 00:11:03,600
The standard technique here is 
using feature flags or feature 

241
00:11:03,600 --> 00:11:05,680
toggles. 
You break the massive feature 

242
00:11:05,680 --> 00:11:07,360
down into tiny, manageable 
chunks. 

243
00:11:07,520 --> 00:11:10,400
Each tiny chunk can be built and
merged into Maine within that 

244
00:11:10,400 --> 00:11:12,480
short time frame, maybe even 
daily. 

245
00:11:12,560 --> 00:11:13,960
But the feature isn't finished 
yet. 

246
00:11:14,120 --> 00:11:17,200
You're merging incomplete code. 
Yes, but you wrap that 

247
00:11:17,200 --> 00:11:19,200
incomplete code in a feature 
flag. 

248
00:11:19,560 --> 00:11:21,120
Think of it like a runtime 
switch. 

249
00:11:21,440 --> 00:11:24,120
The code gets deployed to 
production with Maine, but the 

250
00:11:24,120 --> 00:11:27,440
flag is initially off so users 
don't see the half finished 

251
00:11:27,440 --> 00:11:29,920
feature. 
Developers keep merging small 

252
00:11:29,920 --> 00:11:33,240
pieces behind the flag. 
Only when the entire feature is 

253
00:11:33,240 --> 00:11:36,760
complete, tested and ready do 
you flip the flag on in 

254
00:11:36,760 --> 00:11:40,320
production, making it visible. 
Clever so you maintain the high 

255
00:11:40,320 --> 00:11:44,200
integration frequency even for 
big projects just hiding the 

256
00:11:44,200 --> 00:11:47,560
work in progress. 
OK this paints a clear picture. 

257
00:11:48,160 --> 00:11:51,680
Get flow values that staged 
formal release process. 

258
00:11:51,880 --> 00:11:56,480
GitHub Flow values the pre merge
review via PRS and TBD values 

259
00:11:56,480 --> 00:11:59,840
sheer velocity and continuous 
integration, heavily relying on 

260
00:11:59,840 --> 00:12:01,760
automation and techniques like 
feature flags. 

261
00:12:01,920 --> 00:12:04,200
That's a great summary and the 
choice between them really 

262
00:12:04,200 --> 00:12:05,880
boiled down to your team's 
context. 

263
00:12:06,160 --> 00:12:09,080
What's your tolerance for risk? 
How mature is your automated 

264
00:12:09,080 --> 00:12:11,160
testing? 
Do you need formal sign offs? 

265
00:12:11,320 --> 00:12:13,240
Get flow, Trust the process and 
QA. 

266
00:12:13,480 --> 00:12:14,920
Get help. 
Flow trust the reviewer. 

267
00:12:14,920 --> 00:12:17,640
TBD trust the developer and the 
automation it. 

268
00:12:17,640 --> 00:12:20,000
Really dictates how your team 
operates. 

269
00:12:20,720 --> 00:12:23,240
So we've covered the structured 
world of Get Flow, the review 

270
00:12:23,240 --> 00:12:27,040
focused GitHub Flow, and the 
fast-paced automation heavy 

271
00:12:27,040 --> 00:12:29,560
trunk based development. 
Yeah, and remember, these aren't

272
00:12:29,560 --> 00:12:32,880
just abstract diagrams. 
They directly impact how quickly

273
00:12:32,880 --> 00:12:35,520
ideas turn into code that's 
actually running and delivering 

274
00:12:35,520 --> 00:12:37,880
value. 
It's about the flow of knowledge

275
00:12:37,880 --> 00:12:40,480
into production. 
Thank you for joining us for 

276
00:12:40,480 --> 00:12:43,040
this deep dive into software 
branching strategies.