1
00:00:00,040 --> 00:00:02,320
Imagine you're working on a 
really important project. 

2
00:00:02,320 --> 00:00:05,400
Could be anything, a huge 
presentation, maybe a complex 

3
00:00:05,400 --> 00:00:07,800
design, or you know, the code 
for the next big gap. 

4
00:00:07,920 --> 00:00:10,160
You're totally in the zone 
making critical changes, and 

5
00:00:10,160 --> 00:00:12,800
then bam, you realize you 
actually need to go back to how 

6
00:00:12,800 --> 00:00:15,400
things were last week, maybe 
even last month. 

7
00:00:15,560 --> 00:00:17,640
Oh yeah, that's sinking feeling.
Exactly. 

8
00:00:17,640 --> 00:00:21,480
Or picture this, you're 
collaborating with a whole team,

9
00:00:21,480 --> 00:00:24,800
all working on the very same 
files, and suddenly everyone's 

10
00:00:24,800 --> 00:00:26,520
changes are just trampling over 
each other. 

11
00:00:26,520 --> 00:00:29,640
It's it's digital chaos A. 
Complete mess. 

12
00:00:29,640 --> 00:00:32,600
It sounds like a recipe for 
absolute disaster, right? 

13
00:00:32,759 --> 00:00:36,160
Lost work, massive frustration. 
Definitely. 

14
00:00:36,280 --> 00:00:39,480
OK, let's unpack this. 
Today we're diving deep into 

15
00:00:39,480 --> 00:00:42,360
version control, and this isn't 
just some jargon. 

16
00:00:42,360 --> 00:00:44,880
It's really the core discipline 
that makes modern software 

17
00:00:44,880 --> 00:00:48,080
development and honestly, any 
tricky collaborative digital 

18
00:00:48,080 --> 00:00:52,240
work even possible and 
crucially, safe and efficient. 

19
00:00:52,720 --> 00:00:55,960
So our mission is to explore how
teams manage all these digital 

20
00:00:55,960 --> 00:00:59,560
files, how they track every 
single change and work together 

21
00:00:59,560 --> 00:01:02,600
effectively without ending up in
that chaotic mess we just talked

22
00:01:02,600 --> 00:01:04,200
about. 
It's way more than just hitting 

23
00:01:04,200 --> 00:01:06,640
save. 
It really is that digital chaos 

24
00:01:06,640 --> 00:01:08,640
you painted. 
That's the perfect reason why 

25
00:01:08,640 --> 00:01:10,920
version control is just so 
essential now. 

26
00:01:11,280 --> 00:01:14,520
It's not only about code. 
It really is the backbone for 

27
00:01:14,520 --> 00:01:16,560
any collaborative digital 
effort. 

28
00:01:17,320 --> 00:01:19,800
Version control. 
It's not just a tool, it's 

29
00:01:19,800 --> 00:01:22,680
almost like the silent guardian 
of your project's history. 

30
00:01:23,240 --> 00:01:26,440
It's the engine allowing 
hundreds, maybe thousands of 

31
00:01:26,440 --> 00:01:29,520
people to work on the same thing
without it all falling apart. 

32
00:01:29,800 --> 00:01:32,880
It makes things reliable, let 
you innovate faster because, 

33
00:01:33,120 --> 00:01:35,960
well, failures reversible. 
OK, so let's paint the picture. 

34
00:01:35,960 --> 00:01:38,560
Software development. 
It's almost always a team 

35
00:01:38,560 --> 00:01:40,120
effort, right? 
Almost always, yeah. 

36
00:01:40,360 --> 00:01:44,000
So the second you have more than
one person touching the same 

37
00:01:44,000 --> 00:01:46,840
files, you hit that fundamental 
problem. 

38
00:01:47,240 --> 00:01:49,960
How does everyone keep track? 
How do you make sure your 

39
00:01:49,960 --> 00:01:51,560
changes don't break someone 
else's work? 

40
00:01:51,880 --> 00:01:54,440
And that's where this idea of 
repository comes in. 

41
00:01:55,000 --> 00:01:58,000
You should think of it less like
a simple folder and more like a 

42
00:01:58,520 --> 00:02:02,360
like a secure vault or a version
database for the entire project.

43
00:02:02,360 --> 00:02:04,720
A central hub. 
Yeah, the central nervous system

44
00:02:04,720 --> 00:02:09,600
maybe, where every change, every
file version, all the history is

45
00:02:09,600 --> 00:02:13,680
meticulously tracked. 
And it serves 2 really vital 

46
00:02:13,680 --> 00:02:17,200
purposes, obviously facilitating
that teamwork, but just as 

47
00:02:17,200 --> 00:02:20,000
critical, making sure the 
operations team knows exactly 

48
00:02:20,000 --> 00:02:23,720
which version needs to go live, 
you know, into production with 

49
00:02:23,720 --> 00:02:25,280
certainty. 
And they can know that with 

50
00:02:25,280 --> 00:02:28,800
certainty because the version 
control system, the VCs, it's 

51
00:02:28,800 --> 00:02:31,720
essentially this robust system 
designed purely to track and 

52
00:02:31,720 --> 00:02:35,200
manage every single change made 
to files over time. 

53
00:02:35,520 --> 00:02:38,480
It performs what feels honestly 
almost like a magic trick. 

54
00:02:38,480 --> 00:02:39,920
A magic trick? 
How so? 

55
00:02:39,920 --> 00:02:41,920
What doesn't just keep the 
latest version, it keeps a 

56
00:02:41,920 --> 00:02:45,280
detailed history, like an audit 
trail of every version of every 

57
00:02:45,280 --> 00:02:46,880
file that's ever been in that 
project. 

58
00:02:47,040 --> 00:02:50,000
So developers literally get an 
undo button that can go back 

59
00:02:50,000 --> 00:02:52,280
weeks, months, even years. 
Wow, like a time machine for 

60
00:02:52,280 --> 00:02:54,880
code. 
Pretty much, if you need the 

61
00:02:54,880 --> 00:02:59,320
code as it was six months ago to
debug some weird old issue, or 

62
00:02:59,320 --> 00:03:02,560
maybe restore a stable state 
after something went wrong, you 

63
00:03:02,560 --> 00:03:05,560
can instantly. 
It's incredibly powerful, and 

64
00:03:05,560 --> 00:03:08,800
what's fascinating here is just 
how fundamental this has become.

65
00:03:09,240 --> 00:03:13,080
Our source material basically 
declares it's inconceivable in 

66
00:03:13,080 --> 00:03:15,960
modern software development to 
create any system to matter how 

67
00:03:15,960 --> 00:03:19,000
simple without a VCs. 
Inconceivable. 

68
00:03:19,000 --> 00:03:21,440
That's a strong word. 
It really tells you how deeply 

69
00:03:21,440 --> 00:03:23,480
baked in these systems are now. 
Absolutely. 

70
00:03:23,520 --> 00:03:26,600
But version control itself, it's
not brand new tech, is it? 

71
00:03:26,800 --> 00:03:28,480
It actually has a pretty long 
history. 

72
00:03:28,480 --> 00:03:30,960
That's right, it goes way back. 
Yeah, it's origins are actually 

73
00:03:30,960 --> 00:03:33,840
in the early 1970s. 
That's when you had systems like

74
00:03:33,840 --> 00:03:37,000
SCCS, the source code control 
system being developed for Unix.

75
00:03:37,160 --> 00:03:39,840
That was a pretty big first step
for managing code on shared 

76
00:03:39,840 --> 00:03:42,120
machines. 
Pioneering stuff back then. 

77
00:03:42,200 --> 00:03:45,320
And then things evolved. 
We saw CVS concurrent version 

78
00:03:45,320 --> 00:03:49,160
system pop up in the mid 80s. 
That was a decent step for basic

79
00:03:49,160 --> 00:03:53,520
team collaboration, and then 
later Subversion or SVN as most 

80
00:03:53,520 --> 00:03:56,480
people know it arrived in the 
early 2000s and got really 

81
00:03:56,480 --> 00:03:58,480
popular. 
It was seen as simpler and more 

82
00:03:58,480 --> 00:04:01,080
robust than CVS. 
Right, SVN had a good run. 

83
00:04:01,280 --> 00:04:03,880
And all these early systems, 
they shared a similar structure,

84
00:04:03,880 --> 00:04:05,320
didn't they? 
They were what we call 

85
00:04:05,320 --> 00:04:08,080
centralized systems. 
Exactly centralized. 

86
00:04:08,080 --> 00:04:10,640
They worked on that classic 
client server model. 

87
00:04:10,880 --> 00:04:14,880
So you have one single main 
server holding the entire 

88
00:04:14,880 --> 00:04:16,800
repository, the single source of
truth. 

89
00:04:17,360 --> 00:04:19,800
All of the developers, the 
clients would connect directly 

90
00:04:19,800 --> 00:04:22,000
to that server. 
And when a developer finished 

91
00:04:22,000 --> 00:04:23,680
some work. 
Would they perform a commit? 

92
00:04:24,200 --> 00:04:28,280
That operation basically takes a
snapshot of their changes at 

93
00:04:28,280 --> 00:04:31,360
that moment and logs it 
permanently on that central 

94
00:04:31,360 --> 00:04:34,040
server, making it visible to 
everyone else on the team. 

95
00:04:34,040 --> 00:04:36,720
OK, that makes sense. 
But then things changed quite a 

96
00:04:36,720 --> 00:04:38,160
bit. 
Oh yeah, Here's where it gets 

97
00:04:38,160 --> 00:04:42,040
really interesting. 
The early 2000s saw this, well 

98
00:04:42,120 --> 00:04:45,760
this revolution really with the 
rise of distributed version 

99
00:04:45,760 --> 00:04:49,760
control systems, DVCS systems 
like Bitkeeper, which has its 

100
00:04:49,760 --> 00:04:52,320
own interesting history, 
Mercurial and of course the big 

101
00:04:52,320 --> 00:04:55,920
one get, which came out in 2005.
They just fundamentally changed 

102
00:04:55,920 --> 00:04:57,240
the approach. 
How so? 

103
00:04:57,240 --> 00:05:00,040
What makes them distributed? 
Instead of that client server 

104
00:05:00,040 --> 00:05:03,680
setup, DVCS uses more of a 
peer-to-peer architecture. 

105
00:05:04,520 --> 00:05:07,920
What this means, fundamentally, 
is that each developer has a 

106
00:05:07,920 --> 00:05:12,160
full, complete functional 
version control system, a whole 

107
00:05:12,160 --> 00:05:15,640
copy of the repository history, 
and all right there on their own

108
00:05:15,640 --> 00:05:17,960
machine. 
Wait, everyone has the entire 

109
00:05:17,960 --> 00:05:20,120
repository locally? 
The entire thing. 

110
00:05:20,440 --> 00:05:23,640
Now in practice, teams usually 
still have a designated central 

111
00:05:23,640 --> 00:05:26,280
repository that everyone 
synchronizes with just for 

112
00:05:26,280 --> 00:05:28,920
coordination, but the key 
difference is developers 

113
00:05:28,920 --> 00:05:31,360
primarily work and commit 
changes to their local 

114
00:05:31,360 --> 00:05:34,640
repository first. 
Then they sync up with that 

115
00:05:34,640 --> 00:05:38,760
central 1 using a couple of main
operations, pull which grabs the

116
00:05:38,760 --> 00:05:41,400
latest changes from the central 
repo and updates their local 

117
00:05:41,400 --> 00:05:44,920
copy, and push which sends their
own local commits up to the 

118
00:05:44,920 --> 00:05:47,080
central repo. 
That feels like a pretty major 

119
00:05:47,080 --> 00:05:49,160
shift in architecture if 
everyone's got their own full 

120
00:05:49,160 --> 00:05:50,640
copy locally. 
I mean, doesn't that add 

121
00:05:50,640 --> 00:05:52,160
complexity? 
Why make that switch? 

122
00:05:52,160 --> 00:05:55,040
What's better about this 
distributed way of doing things?

123
00:05:55,240 --> 00:05:57,800
That's a fair question. 
It can see more complex 

124
00:05:57,800 --> 00:06:00,480
initially, especially compared 
to the straightforward central 

125
00:06:00,480 --> 00:06:05,600
model, and look for maybe very 
small Co located teams. 

126
00:06:06,320 --> 00:06:09,880
A centralized system might still
be perfectly fine, but DVCS 

127
00:06:09,880 --> 00:06:13,000
really shines and the reason it 
took over is how well it 

128
00:06:13,000 --> 00:06:16,240
supports large distributed teams
and especially open source 

129
00:06:16,240 --> 00:06:19,040
projects. 
The advantages once you sort of 

130
00:06:19,040 --> 00:06:21,320
dig in, are significant. 
Like what? 

131
00:06:22,160 --> 00:06:26,000
Well, first, because you commit 
locally first, you can work and 

132
00:06:26,000 --> 00:06:29,720
manage versions completely 
offline, no network connection 

133
00:06:29,720 --> 00:06:31,600
needed until you're ready to 
push or pull. 

134
00:06:31,880 --> 00:06:34,360
Huge flexibility boost. 
Right, you're not tied to the 

135
00:06:34,360 --> 00:06:35,520
server. 
Exactly. 

136
00:06:35,640 --> 00:06:37,880
Second, it encourages frequent 
commits. 

137
00:06:38,240 --> 00:06:40,560
You can save your work really 
often, even if it's just a 

138
00:06:40,560 --> 00:06:42,520
partial implementation or 
something you're experimenting 

139
00:06:42,520 --> 00:06:45,480
with directly to your local 
repo, without messing up the 

140
00:06:45,480 --> 00:06:47,000
main code base for everyone 
else. 

141
00:06:47,440 --> 00:06:49,680
So you can save progress without
worrying about breaking the 

142
00:06:49,680 --> 00:06:51,960
build for the team. 
Precisely 3rd. 

143
00:06:52,240 --> 00:06:54,520
Those local commits are executed
in less time. 

144
00:06:55,000 --> 00:06:57,280
They're just faster oerations 
because they're haening right 

145
00:06:57,280 --> 00:07:00,760
there on your machine, not over 
a network to a central server. 

146
00:07:01,080 --> 00:07:02,160
Faster feedback? 
Yep. 

147
00:07:02,880 --> 00:07:05,240
And finally, synchronization is 
more flexible. 

148
00:07:05,400 --> 00:07:09,000
You don't have to just sync with
one main central repo. 

149
00:07:09,320 --> 00:07:12,960
You could set up hierarchies, 
maybe team level repos that then

150
00:07:12,960 --> 00:07:15,640
sync up, or even developers 
pulling changes directly from 

151
00:07:15,640 --> 00:07:17,040
each other. 
Lots more workflow 

152
00:07:17,040 --> 00:07:19,600
possibilities. 
That flexibility does sound 

153
00:07:19,600 --> 00:07:23,440
powerful, especially for big, 
maybe globally distributed 

154
00:07:23,440 --> 00:07:26,280
projects. 
And I mean when you talk DVCS 

155
00:07:26,280 --> 00:07:29,960
today, one name just dominates 
the conversation. 

156
00:07:30,240 --> 00:07:32,520
Git. 
Absolutely, Git is king. 

157
00:07:32,880 --> 00:07:34,840
The origin story is pretty cool 
actually. 

158
00:07:34,840 --> 00:07:37,040
It was developed, as you 
mentioned, under the leadership 

159
00:07:37,080 --> 00:07:39,520
of Linus Torvalds. 
You know, the guy who created 

160
00:07:39,520 --> 00:07:40,600
Linux? 
That's right, the Linux 

161
00:07:40,600 --> 00:07:42,640
connection is key. 
Yeah, because apparently in the 

162
00:07:42,640 --> 00:07:46,200
early days the Linux kernel 
project used that commercial 

163
00:07:46,200 --> 00:07:49,680
system, Bitkeeper. 
But then in 2005, the company 

164
00:07:49,680 --> 00:07:52,600
behind Bitkeeper revoked the 
free licenses they've been 

165
00:07:52,600 --> 00:07:55,720
giving the Linux folks. 
That caused a bit of a crisis. 

166
00:07:55,880 --> 00:07:59,320
Right, so Torvalds and his team 
basically said OK fine, we need 

167
00:07:59,320 --> 00:08:02,240
our own open source system that 
actually works for our massive 

168
00:08:02,240 --> 00:08:05,880
distributed project, and they 
literally built git in like a 

169
00:08:05,880 --> 00:08:07,240
few weeks. 
Incredible. 

170
00:08:07,400 --> 00:08:10,120
An amazing feat born out of 
necessity now. 

171
00:08:10,160 --> 00:08:13,640
Git itself is primarily a 
command line tool, which can 

172
00:08:13,640 --> 00:08:15,400
sound a bit scary for some 
people it. 

173
00:08:15,400 --> 00:08:17,880
Could be intimidating, yeah. 
Lots of commands to learn. 

174
00:08:18,360 --> 00:08:22,400
But thankfully, because it's so 
popular, loads of really good 

175
00:08:22,400 --> 00:08:26,080
third party graphical interfaces
have popped up, so you can use 

176
00:08:26,080 --> 00:08:29,680
git visually clicking buttons 
instead of typing commands, 

177
00:08:29,680 --> 00:08:31,520
which makes it way more 
accessible. 

178
00:08:31,520 --> 00:08:35,159
Definitely lowers the barrier to
entry, and that popularity leads

179
00:08:35,159 --> 00:08:38,480
us perfectly to GitHub. 
It's really important to draw 

180
00:08:38,480 --> 00:08:41,799
this distinction clearly. 
OK, GitHub is not Git. 

181
00:08:42,240 --> 00:08:45,640
GitHub is a code hosting service
that uses the git system. 

182
00:08:46,000 --> 00:08:48,200
Think of it like a web platform 
built on top of GITS 

183
00:08:48,200 --> 00:08:50,800
capabilities. 
So git is the engine, GitHub is 

184
00:08:50,800 --> 00:08:53,760
the car or maybe the garage. 
Kind of, yeah. 

185
00:08:53,920 --> 00:08:57,240
GitHub provides hosting. 
It famously offers free public 

186
00:08:57,240 --> 00:08:59,480
repositories which are wise 
become the heart of the open 

187
00:08:59,480 --> 00:09:04,040
source world and also offers 
paid private repositories for 

188
00:09:04,040 --> 00:09:06,720
companies and corporate use. 
The analogy in our source 

189
00:09:06,720 --> 00:09:08,760
material is pretty good. 
Think about e-mail. 

190
00:09:09,000 --> 00:09:11,440
Instead of installing and 
running your own e-mail server 

191
00:09:11,440 --> 00:09:14,840
locally, which you could do, 
most companies just use a 

192
00:09:14,840 --> 00:09:17,680
service from a third party like 
Google through Gmail. 

193
00:09:17,800 --> 00:09:19,240
Right, you outsource the 
management. 

194
00:09:19,240 --> 00:09:21,960
Exactly. 
Similarly, companies can use 

195
00:09:21,960 --> 00:09:25,600
GitHub or competitors like 
GitLab or Bitbucket instead of 

196
00:09:25,600 --> 00:09:27,800
managing their own internal git 
servers. 

197
00:09:27,880 --> 00:09:28,960
It simplifies things. 
Oh. 

198
00:09:28,960 --> 00:09:32,480
OK, that makes total sense. 
So with git and platforms like 

199
00:09:32,480 --> 00:09:36,320
GitHub being the standard, how 
do organizations actually 

200
00:09:36,320 --> 00:09:40,240
structure their code within 
these systems, especially when 

201
00:09:40,240 --> 00:09:43,280
they have lots of projects? 
This brings us to a really 

202
00:09:43,280 --> 00:09:46,960
interesting strategic decision 
point, the whole multi repos 

203
00:09:46,960 --> 00:09:50,160
versus mono repos debate. 
Yes, the repo strategy question.

204
00:09:50,200 --> 00:09:52,040
It's a big one. 
So what does this all mean? 

205
00:09:52,040 --> 00:09:53,440
Let's break down those terms, 
OK? 

206
00:09:53,640 --> 00:09:56,560
So multi repo is probably the 
approach that feels most 

207
00:09:56,560 --> 00:09:58,920
intuitive initially. 
It's simply where an 

208
00:09:58,920 --> 00:10:03,160
organization sets up 1 
repository for each project or 

209
00:10:03,160 --> 00:10:04,240
system. 
Makes sense. 

210
00:10:04,240 --> 00:10:06,080
Separate projects, separate 
repos. 

211
00:10:06,440 --> 00:10:09,840
Right, if your company, let's 
call it My Org, has three 

212
00:10:09,840 --> 00:10:12,880
different software systems, you 
might have repos like My Org 

213
00:10:12,880 --> 00:10:15,600
System one, My Org System 2, My 
Org System 3. 

214
00:10:15,880 --> 00:10:17,280
Pretty straightforward. 
OK. 

215
00:10:17,360 --> 00:10:19,640
And the alternative? 
Monorepos. 

216
00:10:20,040 --> 00:10:21,920
The Monorepot. 
Approach is quite different. 

217
00:10:21,920 --> 00:10:25,480
Here you have a single 
repository that contains all the

218
00:10:25,480 --> 00:10:27,640
organization's projects. 
These different projects are 

219
00:10:27,640 --> 00:10:31,000
then usually structured just as 
subdirectories inside that one 

220
00:10:31,000 --> 00:10:33,480
giant repository. 
All of them in one place, yeah. 

221
00:10:34,160 --> 00:10:37,480
So using our example, you just 
have one repo, maybe My Oracle, 

222
00:10:37,480 --> 00:10:39,440
the code or something. 
And inside that you'd find 

223
00:10:39,440 --> 00:10:43,040
folders for system 1, system 2, 
system 3, and maybe shared 

224
00:10:43,040 --> 00:10:44,760
libraries, tools, everything 
else. 

225
00:10:45,160 --> 00:10:48,320
And what often surprises people 
is that this mono repo approach,

226
00:10:48,600 --> 00:10:52,560
despite sounding maybe a bit 
nuts, is actually often adopted 

227
00:10:52,560 --> 00:10:55,440
by large companies such as 
Google, Meta and Microsoft. 

228
00:10:55,720 --> 00:10:57,960
Wow, really? 
Google puts all its code in one 

229
00:10:57,960 --> 00:11:01,600
single repository? 
That sounds massive, potentially

230
00:11:01,600 --> 00:11:04,000
incredibly unwieldy. 
Why would they do that? 

231
00:11:04,040 --> 00:11:06,640
What are the advantages of 
having such a gigantic single 

232
00:11:06,640 --> 00:11:08,320
repo? 
It definitely sounds 

233
00:11:08,320 --> 00:11:09,960
counterintuitive at first 
glance. 

234
00:11:10,280 --> 00:11:14,360
And yes, they are unimaginably 
massive repositories, but for 

235
00:11:14,360 --> 00:11:17,360
companies operating at that kind
of scale, the Mono repper offers

236
00:11:17,360 --> 00:11:18,880
some really compelling 
advantages. 

237
00:11:19,040 --> 00:11:20,080
OK. 
I'm curious. 

238
00:11:20,080 --> 00:11:22,680
Well, First off, with everything
in one place, there's zero 

239
00:11:22,680 --> 00:11:26,000
ambiguity about where the latest
version of any piece of code 

240
00:11:26,000 --> 00:11:29,120
lives. 
It creates a true single source 

241
00:11:29,120 --> 00:11:33,120
of truth for all code versions. 
You eliminate a whole category 

242
00:11:33,120 --> 00:11:35,960
of problems related to figuring 
out which version of which 

243
00:11:35,960 --> 00:11:38,680
library works with which version
of which service. 

244
00:11:39,080 --> 00:11:40,680
Consistency. 
Exactly. 

245
00:11:40,680 --> 00:11:44,520
Huge for consistency. 
Second, Mono repos really 

246
00:11:44,520 --> 00:11:46,360
encourage code reuse and 
sharing. 

247
00:11:46,640 --> 00:11:48,120
Because all the code is right 
there. 

248
00:11:48,320 --> 00:11:51,480
It's much easier for developers 
to discover and use libraries or

249
00:11:51,480 --> 00:11:54,600
components built by other teams.
It sort of breaks down silos. 

250
00:11:54,800 --> 00:11:58,520
Easier collaboration across 
teams then. 3rd, and this is a 

251
00:11:58,520 --> 00:12:01,360
big one, changes across multiple
projects can be atomic. 

252
00:12:01,920 --> 00:12:04,640
Imagine you need to fix a bug or
add a feature that affects a 

253
00:12:04,920 --> 00:12:07,560
both system 1 and system two in 
a Mona repo. 

254
00:12:07,560 --> 00:12:10,480
You can often make the necessary
changes to both systems within a

255
00:12:10,480 --> 00:12:12,600
single commit. 
So it all goes in together or 

256
00:12:12,600 --> 00:12:13,840
none of it does. 
Precisely. 

257
00:12:13,880 --> 00:12:17,680
You avoid that awkward state 
where one system is updated but 

258
00:12:17,680 --> 00:12:20,400
the dependency isn't leading to 
things breaking. 

259
00:12:20,720 --> 00:12:23,600
It ensures consistency across 
dependent systems. 

260
00:12:24,120 --> 00:12:27,800
And finally, Mona repos 
facilitate the execution of 

261
00:12:27,800 --> 00:12:31,040
large scale refactorings. 
Like renaming something used 

262
00:12:31,040 --> 00:12:32,400
everywhere. 
Exactly. 

263
00:12:32,400 --> 00:12:35,840
Imagine you need to rename a 
core function or change an API 

264
00:12:35,840 --> 00:12:38,920
that's used by hundreds of 
different internal projects In 

265
00:12:38,920 --> 00:12:41,040
Mona repo. 
You can potentially do that 

266
00:12:41,040 --> 00:12:44,760
entire refactoring across the 
entire code base in one single 

267
00:12:44,760 --> 00:12:46,960
commit. 
That would be incredibly 

268
00:12:46,960 --> 00:12:50,960
difficult and coordination heavy
across dozens or hundreds of 

269
00:12:50,960 --> 00:12:54,360
separate repositories. 
OK, I can see the appeal now, 

270
00:12:54,360 --> 00:12:56,880
especially for coordinating 
changes at massive scale. 

271
00:12:57,160 --> 00:13:00,360
That atomicity and refactoring 
power sound significant, but it 

272
00:13:00,360 --> 00:13:03,120
still sounds like it must come 
with its own set of challenges. 

273
00:13:03,120 --> 00:13:05,000
I mean, managing A repo that 
big? 

274
00:13:05,040 --> 00:13:06,840
Oh. 
Absolutely, you're right to push

275
00:13:06,840 --> 00:13:08,680
back on that. 
Monterepos are definitely not a 

276
00:13:08,680 --> 00:13:10,360
free lunch. 
They come with substantial 

277
00:13:10,360 --> 00:13:13,440
engineering challenges. 
Well for starters, Mono repos 

278
00:13:13,440 --> 00:13:16,560
absolutely require specific 
tools to navigate large code 

279
00:13:16,560 --> 00:13:18,920
bases. 
Our source mentions Google had 

280
00:13:18,920 --> 00:13:22,400
to build custom plug insurance 
for their ID ES just so 

281
00:13:22,400 --> 00:13:24,840
developers could effectively 
work with their code base 

282
00:13:25,200 --> 00:13:27,640
without getting totally lost or 
bogged down. 

283
00:13:27,960 --> 00:13:30,280
Standard tools often just don't 
scale. 

284
00:13:30,520 --> 00:13:31,720
Right, the tooling has to keep 
up. 

285
00:13:31,920 --> 00:13:34,360
Exactly. 
You also need incredibly 

286
00:13:34,360 --> 00:13:37,720
sophisticated build systems. 
You can't afford to rebuild the 

287
00:13:37,720 --> 00:13:40,320
entire code base every time 
someone makes a small change. 

288
00:13:40,920 --> 00:13:43,840
The build system needs to be 
smart enough to only build the 

289
00:13:43,840 --> 00:13:45,480
specific things that were 
affected. 

290
00:13:45,480 --> 00:13:47,800
Performance becomes critical. 
Hugely critical. 

291
00:13:48,040 --> 00:13:51,200
You also need very fine grained 
access controls because you 

292
00:13:51,200 --> 00:13:53,680
probably don't want every single
developer to have access to all 

293
00:13:53,680 --> 00:13:55,720
the code, especially sensitive 
parts. 

294
00:13:56,240 --> 00:13:58,160
And yeah, there can be 
performance hurdles just 

295
00:13:58,160 --> 00:14:01,720
checking out or updating such a 
massive repository, even with 

296
00:14:01,720 --> 00:14:04,480
optimized tooling. 
It's a significant investment in

297
00:14:04,480 --> 00:14:06,720
infrastructure, tooling and 
processes. 

298
00:14:06,960 --> 00:14:10,200
So it's a solution tailored for 
a specific kind of scale and set

299
00:14:10,200 --> 00:14:12,720
of problems, not necessarily 
universal best practice. 

300
00:14:12,960 --> 00:14:14,280
Precisely. 
It's a trade off. 

301
00:14:14,360 --> 00:14:17,240
It solves some complex 
coordination problems, but 

302
00:14:17,240 --> 00:14:19,920
introduces new challenges around
tooling and scale. 

303
00:14:20,240 --> 00:14:23,240
It works for Google, Meta, 
Microsoft, but it might be 

304
00:14:23,240 --> 00:14:26,720
overkill or even detrimental for
smaller organizations. 

305
00:14:27,000 --> 00:14:29,160
It's amazing really, just 
thinking about the sheer 

306
00:14:29,160 --> 00:14:32,280
complexity hidden beneath the 
surface of the apps and services

307
00:14:32,280 --> 00:14:35,600
we use everyday, all built on 
these layers of version control.

308
00:14:35,600 --> 00:14:39,520
So we've gone from why version 
control is absolutely essential,

309
00:14:39,520 --> 00:14:42,720
that bedrock for collaboration 
and history through its 

310
00:14:42,720 --> 00:14:45,560
evolution from centralized 
systems to the distributed world

311
00:14:45,560 --> 00:14:47,520
of Git. 
And then looked at these big 

312
00:14:47,520 --> 00:14:50,720
strategic choices companies face
with multi repos versus those 

313
00:14:50,720 --> 00:14:54,160
giant mana repos, understanding 
the pros and cons, especially at

314
00:14:54,160 --> 00:14:56,240
scale. 
It really hammers home that 

315
00:14:56,240 --> 00:14:59,440
version control isn't just a 
minor technical detail, it's 

316
00:14:59,440 --> 00:15:02,120
truly a foundational pillar 
supporting modern software 

317
00:15:02,120 --> 00:15:04,200
engineering. 
It's what enables the scale, the

318
00:15:04,200 --> 00:15:06,120
speed, the collaboration we see 
today. 

319
00:15:06,360 --> 00:15:08,680
It lets teams build these 
incredibly complex things 

320
00:15:08,680 --> 00:15:11,560
reliably, efficiently, without 
getting lost in the history or 

321
00:15:11,560 --> 00:15:14,560
fearing mistakes. 
So as we wrap up this deep dive,

322
00:15:14,560 --> 00:15:17,000
maybe the thought to leave you 
with is that version control is 

323
00:15:17,000 --> 00:15:19,240
fundamentally about managing 
change. 

324
00:15:19,520 --> 00:15:22,800
And in our constantly evolving 
digital world, that ability is 

325
00:15:22,800 --> 00:15:24,960
everything. 
It lets us build, innovate, fix 

326
00:15:24,960 --> 00:15:26,800
things things, and work together
effectively. 

327
00:15:27,080 --> 00:15:29,720
So next time you save a file or 
collaborate on any kind of 

328
00:15:29,720 --> 00:15:33,200
digital project, maybe spare a 
thought for the hidden systems 

329
00:15:33,200 --> 00:15:36,160
making it all work smoothly. 
Thank you for joining us on this

330
00:15:36,160 --> 00:15:36,720
deep dive.