Git - Simply Explained

1
00:00:00,000 --> 00:00:03,340
You change one small thing after hours of work, save the file,

2
00:00:03,340 --> 00:00:06,000
and suddenly the part that worked yesterday doesn't work anymore.

3
00:00:06,000 --> 00:00:08,180
Now you're hunting through folders named Project Final,

4
00:00:08,180 --> 00:00:10,720
Project Final Final, and Project Use This One.

5
00:00:10,720 --> 00:00:11,960
Git fixes that mess.

6
00:00:11,960 --> 00:00:16,340
I'm Mirko Peters from M365, FM, and this knowledge nugget explains Git in plain English.

7
00:00:16,340 --> 00:00:18,480
You'll see how it keeps a usable history of your project,

8
00:00:18,480 --> 00:00:20,240
how GitHub fits into the picture,

9
00:00:20,240 --> 00:00:24,280
and why teams rely on both without copying folders all day.

10
00:00:24,280 --> 00:00:25,800
Git is your project history.

11
00:00:25,800 --> 00:00:27,200
Git is a version control system.

12
00:00:27,200 --> 00:00:29,960
That sounds technical, but the idea is simple.

13
00:00:29,960 --> 00:00:32,360
Git keeps a recorded history of a project,

14
00:00:32,360 --> 00:00:33,960
so you can see what changed,

15
00:00:33,960 --> 00:00:36,400
and return to an earlier point when you need to.

16
00:00:36,400 --> 00:00:40,480
Imagine you're building a small website with a login page on Monday the page works.

17
00:00:40,480 --> 00:00:43,560
The email box, password box, and sign-in button all look right.

18
00:00:43,560 --> 00:00:47,240
Instead of copying the whole folder and calling it "log-in page working",

19
00:00:47,240 --> 00:00:50,040
you tell Git "this is a version worth keeping".

20
00:00:50,040 --> 00:00:52,240
Git records that point in the project's history.

21
00:00:52,240 --> 00:00:54,240
On Tuesday you add a new sign-in option.

22
00:00:54,240 --> 00:00:55,840
On Wednesday you change the page layout.

23
00:00:55,840 --> 00:00:58,720
By Thursday the button has moved, the page looks wrong on a phone,

24
00:00:58,720 --> 00:01:00,720
and you're not sure which edit caused the problem.

25
00:01:00,720 --> 00:01:04,400
Without Git you might dig through old folders or try to undo changes by hand.

26
00:01:04,400 --> 00:01:08,520
With Git you can look back through the checkpoints and compare the working version with the broken one.

27
00:01:08,520 --> 00:01:09,840
You can see which files changed,

28
00:01:09,840 --> 00:01:12,320
and often which lines inside those files changed.

29
00:01:12,320 --> 00:01:14,400
That makes finding the problem much less like guessing.

30
00:01:14,400 --> 00:01:17,520
Those checkpoints have a name and git, they're called "commits".

31
00:01:17,520 --> 00:01:21,840
A commit is not every time you press "save in word" or "save a file" in your editor.

32
00:01:21,840 --> 00:01:26,280
Git doesn't quietly capture every keystroke you choose when a piece of work deserves a checkpoint.

33
00:01:26,280 --> 00:01:27,880
Maybe you fix the login error.

34
00:01:27,880 --> 00:01:29,680
Maybe you added the apple sign-in button.

35
00:01:29,680 --> 00:01:33,560
Maybe you changed the text on the welcome screen because the old wording confused users.

36
00:01:33,560 --> 00:01:37,320
When that piece of work is ready you create a commit and write a short message about it.

37
00:01:37,320 --> 00:01:41,520
Something like "add apple sign-in option" or "fix password reset link".

38
00:01:41,520 --> 00:01:43,760
That message matters more than people think.

39
00:01:43,760 --> 00:01:47,000
Six months later you or someone else can read the project history

40
00:01:47,000 --> 00:01:49,160
and understand the reason for a change.

41
00:01:49,160 --> 00:01:54,120
Updates and stuff changed don't help much when you're trying to find a bug on a busy Friday afternoon.

42
00:01:54,120 --> 00:01:56,240
A good commit covers one clear piece of work.

43
00:01:56,240 --> 00:01:59,480
If you change the login page and rebuild the whole navigation menu,

44
00:01:59,480 --> 00:02:01,080
those may belong in separate commits.

45
00:02:01,080 --> 00:02:04,600
Separate checkpoints make it easier to review work, understand history,

46
00:02:04,600 --> 00:02:07,000
and undo one change without touching another.

47
00:02:07,000 --> 00:02:09,640
Now many people think git only matters when you work with a team.

48
00:02:09,640 --> 00:02:11,400
It helps teams, but it starts with you.

49
00:02:11,400 --> 00:02:13,800
Git runs on your computer and keeps its history there.

50
00:02:13,800 --> 00:02:17,400
You can create commits while you're offline on a train at home or anywhere else.

51
00:02:17,400 --> 00:02:19,880
Nothing needs to go online for Git to record your work.

52
00:02:19,880 --> 00:02:23,960
That local first design is easy to miss because people often meet Git through GitHub.

53
00:02:23,960 --> 00:02:25,640
But Git and GitHub aren't the same thing.

54
00:02:25,640 --> 00:02:27,920
Git is the tool that tracks your project history.

55
00:02:27,920 --> 00:02:30,520
GitHub is an online place where people can share that history.

56
00:02:30,520 --> 00:02:33,000
We'll get to that shortly, but keep this difference in your head.

57
00:02:33,000 --> 00:02:34,320
Git works locally first.

58
00:02:34,320 --> 00:02:35,640
Why does Git fit code so well?

59
00:02:35,640 --> 00:02:37,440
Code changes in small parts.

60
00:02:37,440 --> 00:02:38,840
One line might fix a problem.

61
00:02:38,840 --> 00:02:40,200
Another line might create one.

62
00:02:40,200 --> 00:02:43,120
Developers need to know who changed a file, what they changed,

63
00:02:43,120 --> 00:02:44,880
and when that change entered the project.

64
00:02:44,880 --> 00:02:45,960
Git gives you that trail.

65
00:02:45,960 --> 00:02:47,400
It can compare one commit with another.

66
00:02:47,400 --> 00:02:49,480
It can show a shared history across a team.

67
00:02:49,480 --> 00:02:52,000
It can help you return to an earlier version

68
00:02:52,000 --> 00:02:54,440
when a new change breaks something that used to work.

69
00:02:54,440 --> 00:02:56,600
You can use Git for other kinds of files too,

70
00:02:56,600 --> 00:02:59,440
although it works best when it can read and compare text.

71
00:02:59,440 --> 00:03:03,160
Code, notes, website files, and settings files all fit naturally.

72
00:03:03,160 --> 00:03:05,040
So think of Git as your project's memory,

73
00:03:05,040 --> 00:03:07,640
not a magic undo button, and not a coding language.

74
00:03:07,640 --> 00:03:09,240
It's a system for creating deliberate,

75
00:03:09,240 --> 00:03:11,400
named checkpoints that you can inspect later,

76
00:03:11,400 --> 00:03:13,880
but a checkpoint needs somewhere to live on your computer.

77
00:03:13,880 --> 00:03:15,200
To understand that part,

78
00:03:15,200 --> 00:03:18,480
picture where your work sits before Git turns it into history.

79
00:03:18,480 --> 00:03:19,760
The three local areas.

80
00:03:19,760 --> 00:03:23,400
Git uses three local places to move a change from active work into recorded history.

81
00:03:23,400 --> 00:03:24,600
Think of a normal office.

82
00:03:24,600 --> 00:03:26,480
You have your desk where you do your work.

83
00:03:26,480 --> 00:03:29,760
You have a review tray where you place the papers ready for filing.

84
00:03:29,760 --> 00:03:33,280
Then you have a filing cabinet where approved papers stay as part of the record.

85
00:03:33,280 --> 00:03:35,400
Your Git project works in much the same way.

86
00:03:35,400 --> 00:03:37,320
The first place is the working directory.

87
00:03:37,320 --> 00:03:40,160
That simply means the normal project folder on your computer.

88
00:03:40,160 --> 00:03:43,760
It might contain your website files, your notes, your images, and your settings.

89
00:03:43,760 --> 00:03:47,040
Your open files there, change them, create new ones, and delete old ones.

90
00:03:47,040 --> 00:03:49,320
When you edit the login page in your code editor,

91
00:03:49,320 --> 00:03:50,960
you're working in the working directory.

92
00:03:50,960 --> 00:03:52,400
This is your desk.

93
00:03:52,400 --> 00:03:53,600
It can be messy.

94
00:03:53,600 --> 00:03:54,800
That's fine.

95
00:03:54,800 --> 00:03:56,680
You might start changing the sign-in button,

96
00:03:56,680 --> 00:03:59,480
then notice a spelling mistake in another file.

97
00:03:59,480 --> 00:04:03,080
You may create a new file to test an idea, then decide you don't need it.

98
00:04:03,080 --> 00:04:05,960
Git doesn't force every change into the project history,

99
00:04:05,960 --> 00:04:07,800
just because it happened in this folder.

100
00:04:07,800 --> 00:04:09,160
Before you save a checkpoint,

101
00:04:09,160 --> 00:04:11,720
you usually want to know what Git can see.

102
00:04:11,720 --> 00:04:14,400
That is where a command called GitStatus helps.

103
00:04:14,400 --> 00:04:16,800
In plain English, GitStatus asks Git,

104
00:04:16,800 --> 00:04:20,000
"What has changed in this project since the last recorded checkpoint?"

105
00:04:20,000 --> 00:04:24,080
Git can tell you that a file changed, that a file is new, or that a file has been removed.

106
00:04:24,080 --> 00:04:27,120
It can also tell you which changes are ready for the next commit,

107
00:04:27,120 --> 00:04:29,480
and which ones are still only sitting on your desk.

108
00:04:29,480 --> 00:04:32,160
For a beginner, this command becomes a safety check.

109
00:04:32,160 --> 00:04:34,320
If you're unsure where you are, run GitStatus.

110
00:04:34,320 --> 00:04:36,200
Imagine you changed the login page,

111
00:04:36,200 --> 00:04:38,400
edit a help file, and removed an old image.

112
00:04:38,400 --> 00:04:42,400
Before you record anything, GitStatus gives you a simple view of that situation.

113
00:04:42,400 --> 00:04:43,720
You don't need to trust your memory.

114
00:04:43,720 --> 00:04:45,400
The second place is the staging area.

115
00:04:45,400 --> 00:04:49,280
This name confuses many people because it sounds like a technical storage room.

116
00:04:49,280 --> 00:04:51,440
Think of it as the review tray beside your desk.

117
00:04:51,440 --> 00:04:55,120
You place only the changes you want in your next checkpoint into that tray.

118
00:04:55,120 --> 00:04:57,760
Suppose you fixed an error in the password reset link,

119
00:04:57,760 --> 00:05:01,240
but you also started an unfinished redesign of the welcome screen.

120
00:05:01,240 --> 00:05:03,040
You don't want both changes in one commit,

121
00:05:03,040 --> 00:05:05,400
the password fix is ready, the redesign isn't.

122
00:05:05,400 --> 00:05:08,280
So you select the password reset file for the staging area.

123
00:05:08,280 --> 00:05:09,920
The command for that is GitAdd,

124
00:05:09,920 --> 00:05:11,760
followed by the file you want to prepare.

125
00:05:11,760 --> 00:05:14,760
Despite the name, GitAdd doesn't permanently save the change.

126
00:05:14,760 --> 00:05:16,280
It doesn't send anything online either.

127
00:05:16,280 --> 00:05:20,360
It just places a chosen version of that file into the review tray for the next commit.

128
00:05:20,360 --> 00:05:22,000
That small pause gives you control.

129
00:05:22,000 --> 00:05:26,360
You can check the stage changes, remove something from the staging area if you picked it too early,

130
00:05:26,360 --> 00:05:29,120
or add another file if it belongs with the same piece of work.

131
00:05:29,120 --> 00:05:31,280
The point is not to stage every change automatically.

132
00:05:31,280 --> 00:05:34,480
The point is to decide what this one checkpoint should contain.

133
00:05:34,480 --> 00:05:37,320
A useful habit is to keep one commit focused.

134
00:05:37,320 --> 00:05:39,440
Fix password reset link is clear.

135
00:05:39,440 --> 00:05:43,520
Fix password reset link, change the header, update colors, and clean up random files.

136
00:05:43,520 --> 00:05:45,920
Tells a future team made far too much happen at once.

137
00:05:45,920 --> 00:05:49,800
Small clear commits are easier to check and easier to undo when something goes wrong.

138
00:05:49,800 --> 00:05:54,840
Once the review tray contains the exact changes you want, they move to the third place, the local repository.

139
00:05:54,840 --> 00:05:56,320
This is the filing cabinet.

140
00:05:56,320 --> 00:06:00,000
The local repository stores your commits and the project history on your computer.

141
00:06:00,000 --> 00:06:02,520
Git creates and manages the hidden files that hold that history,

142
00:06:02,520 --> 00:06:04,880
so you normally don't need to open or edit them yourself.

143
00:06:04,880 --> 00:06:07,880
To create the checkpoint, you use Git commit and write a message.

144
00:06:07,880 --> 00:06:12,640
For example, Git commit, M, fix password reset link.

145
00:06:12,640 --> 00:06:15,200
That tells Git to take the changes already in the staging area

146
00:06:15,200 --> 00:06:17,920
and record them together as one point in the project history.

147
00:06:17,920 --> 00:06:19,040
Notice the order.

148
00:06:19,040 --> 00:06:20,880
You edit a file in the working directory.

149
00:06:20,880 --> 00:06:23,200
You check your situation with Git status.

150
00:06:23,200 --> 00:06:25,920
You choose what belongs in the checkpoint with Git ad.

151
00:06:25,920 --> 00:06:28,640
Then you record that selected work with Git commit.

152
00:06:28,640 --> 00:06:32,520
Nothing in that root requires GitHub, a browser, or an internet connection.

153
00:06:32,520 --> 00:06:34,840
Everything so far happens on your own computer.

154
00:06:34,840 --> 00:06:37,840
The review tray also explains something beginners often miss.

155
00:06:37,840 --> 00:06:41,720
If you change a file after staging it, Git can treat the new edit separately.

156
00:06:41,720 --> 00:06:44,400
The staged copy reflects what you selected at that time,

157
00:06:44,400 --> 00:06:47,160
while the latest edit remains on your desk until you select it too.

158
00:06:47,160 --> 00:06:48,560
It sounds fussy at first.

159
00:06:48,560 --> 00:06:51,520
Then you work on a real project with several half-finished changes

160
00:06:51,520 --> 00:06:52,880
and it starts to feel practical.

161
00:06:52,880 --> 00:06:54,560
Your working directory is where you work.

162
00:06:54,560 --> 00:06:55,960
The staging area is where you choose.

163
00:06:55,960 --> 00:06:58,720
The local repository is where Git records the choice

164
00:06:58,720 --> 00:07:01,320
that gives one person a much safer way to work.

165
00:07:01,320 --> 00:07:03,520
But projects also need a safe way to try ideas

166
00:07:03,520 --> 00:07:06,080
without disturbing the version everyone trusts.

167
00:07:06,080 --> 00:07:08,400
Branches, merges, and conflicts.

168
00:07:08,400 --> 00:07:10,880
A commit gives you a safe point in history.

169
00:07:10,880 --> 00:07:14,080
A branch gives you a safe place to work on what comes next.

170
00:07:14,080 --> 00:07:15,880
Most projects have a branch called main.

171
00:07:15,880 --> 00:07:19,280
Think of main as the version of the project the team currently trusts.

172
00:07:19,280 --> 00:07:22,280
It holds the work that has already been checked and accepted.

173
00:07:22,280 --> 00:07:24,720
You don't always want to change that trusted version directly.

174
00:07:24,720 --> 00:07:27,480
Imagine the login page works, but you want to add a sign-in option

175
00:07:27,480 --> 00:07:28,760
using a company account.

176
00:07:28,760 --> 00:07:30,280
It might take several files.

177
00:07:30,280 --> 00:07:32,080
You may need to change the page, add a new button,

178
00:07:32,080 --> 00:07:33,840
and update the logic behind it.

179
00:07:33,840 --> 00:07:36,000
During that work, some parts may not work yet.

180
00:07:36,000 --> 00:07:38,200
You don't want half-finished work mixed into main,

181
00:07:38,200 --> 00:07:39,440
so you create a branch.

182
00:07:39,440 --> 00:07:41,800
A branch is a separate line of work that begins

183
00:07:41,800 --> 00:07:43,720
from the current project version.

184
00:07:43,720 --> 00:07:45,920
It isn't a second folder that you keep copying around.

185
00:07:45,920 --> 00:07:48,720
Get remembers the shared history, then records only the changes

186
00:07:48,720 --> 00:07:50,400
that belong to the new line of work.

187
00:07:50,400 --> 00:07:52,720
You might name that branch ad company login.

188
00:07:52,720 --> 00:07:54,520
At the start, it looks the same as main

189
00:07:54,520 --> 00:07:57,120
because both branches begin at the same commit.

190
00:07:57,120 --> 00:07:59,320
Once you start changing files and creating commits,

191
00:07:59,320 --> 00:08:01,720
the branch starts building its own history.

192
00:08:01,720 --> 00:08:03,720
Your new sign-in button can be unfinished there.

193
00:08:03,720 --> 00:08:05,720
You can test ideas, you can change your mind.

194
00:08:05,720 --> 00:08:08,120
You can create several commits as the work takes shape.

195
00:08:08,120 --> 00:08:11,320
While main keeps showing the version everyone already relies on.

196
00:08:11,320 --> 00:08:14,720
That separation matters when more than one person works on the project.

197
00:08:14,720 --> 00:08:17,520
One developer can repair a password problem on one branch

198
00:08:17,520 --> 00:08:19,720
while another adds company sign-in on another.

199
00:08:19,720 --> 00:08:22,720
Neither person needs to wait for the other just to start work.

200
00:08:22,720 --> 00:08:25,720
When the company sign-in option works and the team has checked it,

201
00:08:25,720 --> 00:08:27,520
you can bring the branch back into main.

202
00:08:27,520 --> 00:08:28,920
That action is called a merge.

203
00:08:28,920 --> 00:08:32,320
A merge combines the approved changes from one branch into another branch.

204
00:08:32,320 --> 00:08:35,520
In this case, Git looks at the work from ad company login

205
00:08:35,520 --> 00:08:37,120
and brings the right changes into main.

206
00:08:37,120 --> 00:08:38,720
Git can usually do this on its own.

207
00:08:38,720 --> 00:08:43,120
For example, if one branch changes the sign-in page and another branch changes a help document,

208
00:08:43,120 --> 00:08:45,120
Git can see that those changes don't overlap.

209
00:08:45,120 --> 00:08:47,720
It combines them without needing anyone to step in.

210
00:08:47,720 --> 00:08:50,520
But sometimes two people change the same part of the same file.

211
00:08:50,520 --> 00:08:53,720
Suppose you change the text beside the password field on your branch.

212
00:08:53,720 --> 00:08:57,320
At the same time, another person changes that exact text on main,

213
00:08:57,320 --> 00:08:58,920
but they choose different wording.

214
00:08:58,920 --> 00:09:00,920
Git sees two possible versions.

215
00:09:00,920 --> 00:09:02,920
It can't know which wording the team intends to keep

216
00:09:02,920 --> 00:09:06,520
because Git understands file changes, not the meaning behind a decision.

217
00:09:06,520 --> 00:09:08,520
So it stops the merge and shows a conflict.

218
00:09:08,520 --> 00:09:10,320
A conflict doesn't mean the project is broken.

219
00:09:10,320 --> 00:09:12,520
It means Git needs a person to make the choice.

220
00:09:12,520 --> 00:09:15,120
Your editor will show both versions of the conflicting section.

221
00:09:15,120 --> 00:09:18,120
You read them, decide whether to keep yours, keep the other persons,

222
00:09:18,120 --> 00:09:20,520
or combine both, then save the final text.

223
00:09:20,520 --> 00:09:24,320
After that, you mark the resolved file as ready and create the merge commit.

224
00:09:24,320 --> 00:09:26,720
The project history now records the final choice.

225
00:09:26,720 --> 00:09:30,520
That is much better than Git guessing and silently deleting somebody's work.

226
00:09:30,520 --> 00:09:32,720
Conflicts can feel alarming the first time you see them,

227
00:09:32,720 --> 00:09:34,320
but they are Git being careful.

228
00:09:34,320 --> 00:09:35,520
You still need to slow down.

229
00:09:35,520 --> 00:09:37,520
Don't just choose the first option in your editor

230
00:09:37,520 --> 00:09:39,320
because it makes the warning disappear.

231
00:09:39,320 --> 00:09:41,120
Look at what each change tried to do.

232
00:09:41,120 --> 00:09:44,120
If you aren't sure, ask the person who wrote the other change.

233
00:09:44,120 --> 00:09:46,920
The best final version may include work from both branches.

234
00:09:46,920 --> 00:09:49,320
There is one habit that keeps conflicts smaller.

235
00:09:49,320 --> 00:09:50,920
Keep branches short-lived.

236
00:09:50,920 --> 00:09:53,320
If you create a branch, work on it for three weeks,

237
00:09:53,320 --> 00:09:55,320
and ignore changes arriving on main,

238
00:09:55,320 --> 00:09:57,920
your branch drifts away from the shared project.

239
00:09:57,920 --> 00:09:59,520
By the time you try to merge it,

240
00:09:59,520 --> 00:10:02,120
many files may have changed in both places.

241
00:10:02,120 --> 00:10:03,920
That creates harder decisions.

242
00:10:03,920 --> 00:10:05,720
Instead, make a focused change.

243
00:10:05,720 --> 00:10:08,720
Bring the latest changes from main into your branch regularly

244
00:10:08,720 --> 00:10:11,520
and merge your completed work back sooner.

245
00:10:11,520 --> 00:10:14,920
Smaller changes are easier to understand, easier to review,

246
00:10:14,920 --> 00:10:16,320
and less likely to collide.

247
00:10:16,320 --> 00:10:19,320
So a branch gives you a separate route for a piece of work,

248
00:10:19,320 --> 00:10:22,520
a merge brings that route back into the trusted project version.

249
00:10:22,520 --> 00:10:26,320
And the conflict is Git pausing when two routes reach the same point

250
00:10:26,320 --> 00:10:27,520
with different answers.

251
00:10:27,520 --> 00:10:29,320
Branch is protect your work locally,

252
00:10:29,320 --> 00:10:30,920
but a team also needs one shared place

253
00:10:30,920 --> 00:10:33,320
where everyone can see the same project history.

254
00:10:33,320 --> 00:10:35,720
GitHub, the shared online repository,

255
00:10:35,720 --> 00:10:37,920
branches solve a problem on your computer.

256
00:10:37,920 --> 00:10:39,720
GitHub solves the next problem.

257
00:10:39,720 --> 00:10:42,520
How does the rest of the team see that work?

258
00:10:42,520 --> 00:10:44,120
Git and GitHub have similar names,

259
00:10:44,120 --> 00:10:45,720
so people often treat them as one thing.

260
00:10:45,720 --> 00:10:46,520
They aren't.

261
00:10:46,520 --> 00:10:49,320
Git is the history tool installed on your computer.

262
00:10:49,320 --> 00:10:52,120
GitHub is an online platform where a team can store,

263
00:10:52,120 --> 00:10:54,720
share, discuss, and review Git repositories.

264
00:10:54,720 --> 00:10:57,720
Think of GitHub as the shared project space for a team.

265
00:10:57,720 --> 00:11:00,120
You still have your own copy of the project on your laptop,

266
00:11:00,120 --> 00:11:01,920
including your own commits and branches.

267
00:11:01,920 --> 00:11:05,120
GitHub holds a shared online copy, called a remote repository.

268
00:11:05,120 --> 00:11:08,120
Remote simply means it lives somewhere other than your computer.

269
00:11:08,120 --> 00:11:10,720
That shared copy gives the team one place to meet.

270
00:11:10,720 --> 00:11:13,320
If you work from home one day and from another computer the next,

271
00:11:13,320 --> 00:11:16,720
the remote repository gives you a place to retrieve the project history.

272
00:11:16,720 --> 00:11:19,520
More importantly, it lets colleagues exchange their work

273
00:11:19,520 --> 00:11:21,920
without emailing zip files back and forth.

274
00:11:21,920 --> 00:11:23,520
There are three words you'll hear all the time,

275
00:11:23,520 --> 00:11:24,920
push, pull, and clone.

276
00:11:24,920 --> 00:11:28,120
A push sends commits from your local Git repository up to GitHub.

277
00:11:28,120 --> 00:11:30,920
Say you finished the company sign an option on your branch.

278
00:11:30,920 --> 00:11:33,920
Your commits exist on your computer, but nobody else can see them yet.

279
00:11:33,920 --> 00:11:36,720
When you push that branch, GitHub receives those commits

280
00:11:36,720 --> 00:11:38,920
and makes the branch available to the team.

281
00:11:38,920 --> 00:11:40,120
A pull does the opposite.

282
00:11:40,120 --> 00:11:43,120
Someone else may have merged a bug fix or added a new file

283
00:11:43,120 --> 00:11:44,320
to the shared project.

284
00:11:44,320 --> 00:11:48,520
A pull brings those shared changes from GitHub down into your local copy

285
00:11:48,520 --> 00:11:50,520
so you can work from the same current version.

286
00:11:50,520 --> 00:11:53,920
And a clone is how you begin when a project already exists on GitHub.

287
00:11:53,920 --> 00:11:57,120
Instead of creating an empty folder and building every connection yourself,

288
00:11:57,120 --> 00:11:58,520
you clone the repository.

289
00:11:58,520 --> 00:12:02,120
Git downloads a working copy of the files and the project history onto your computer

290
00:12:02,120 --> 00:12:05,520
then connects that local copy to the shared online repository.

291
00:12:05,520 --> 00:12:09,520
So clone means give me my own connected copy of this project.

292
00:12:09,520 --> 00:12:12,520
Push means send my committed work to the shared copy.

293
00:12:12,520 --> 00:12:15,520
Pull means bring the team's latest work into my copy.

294
00:12:15,520 --> 00:12:18,920
Those words describe direction. That's all.

295
00:12:18,920 --> 00:12:21,720
GitHub also adds a team process around branches.

296
00:12:21,720 --> 00:12:24,920
When your branches ready, you usually don't merge it into main alone.

297
00:12:24,920 --> 00:12:26,920
You open a pull request, despite the name,

298
00:12:26,920 --> 00:12:29,320
a pull request isn't mainly about downloading anything.

299
00:12:29,320 --> 00:12:33,120
It's a request that says, "Please look at the changes on my branch

300
00:12:33,120 --> 00:12:36,520
and if they're ready, bring them into this other branch."

301
00:12:36,520 --> 00:12:38,320
Usually that other branch is main.

302
00:12:38,320 --> 00:12:41,720
On the pull request page, your teammates can see the commits,

303
00:12:41,720 --> 00:12:44,520
the files you changed, and the exact lines that changed.

304
00:12:44,520 --> 00:12:47,320
They can leave comments beside a line of code, ask a question,

305
00:12:47,320 --> 00:12:49,320
suggest a better approach or approve the work.

306
00:12:49,320 --> 00:12:51,920
This moves the conversation next to the change itself.

307
00:12:51,920 --> 00:12:55,520
No more message that says, "Can you look at that thing I sent yesterday?"

308
00:12:55,520 --> 00:12:59,720
The review has a clear record attached to the exact work under discussion.

309
00:12:59,720 --> 00:13:03,520
Many teams also run automated checks when a pull request opens or changes.

310
00:13:03,520 --> 00:13:07,320
For example, a service can try to build the project, run tests,

311
00:13:07,320 --> 00:13:10,520
check code style, or scan for known security problems.

312
00:13:10,520 --> 00:13:14,320
GitHub reports whether those checks passed or failed before the change reaches main.

313
00:13:14,320 --> 00:13:16,120
The checks don't replace human review.

314
00:13:16,120 --> 00:13:17,920
A test can tell you whether a rule passed.

315
00:13:17,920 --> 00:13:20,720
It can't always tell you whether the feature solves the right problem

316
00:13:20,720 --> 00:13:22,920
or whether the new text makes sense to a user.

317
00:13:22,920 --> 00:13:23,920
People still make that call.

318
00:13:23,920 --> 00:13:27,320
Once the review is complete and the checks pass, the pull request can merge.

319
00:13:27,320 --> 00:13:29,920
The approved branch changes enter the shared main branch

320
00:13:29,920 --> 00:13:31,920
and everyone can pull that updated version.

321
00:13:31,920 --> 00:13:35,920
GitHub is a familiar choice, but it isn't the only place to host Git repositories.

322
00:13:35,920 --> 00:13:38,720
GitLab, Bitbucket, and services inside platforms,

323
00:13:38,720 --> 00:13:41,120
such as Azure DevOps, can do similar jobs.

324
00:13:41,120 --> 00:13:43,120
The name of the website can change.

325
00:13:43,120 --> 00:13:45,120
The Git ideas stay the same.

326
00:13:45,120 --> 00:13:47,920
Each person works locally, shares committed work online,

327
00:13:47,920 --> 00:13:50,920
and uses review before changing the version the team trusts.

328
00:13:50,920 --> 00:13:52,920
A Git-based team workflow.

329
00:13:52,920 --> 00:13:57,120
Imagine you arrive on Monday morning and need to fix a small problem in the login page.

330
00:13:57,120 --> 00:14:00,120
Before changing anything, you update your local copy from main,

331
00:14:00,120 --> 00:14:04,320
you pull the latest shared changes because someone may have merged work while you were away.

332
00:14:04,320 --> 00:14:07,320
Starting from an old version creates avoidable problems later,

333
00:14:07,320 --> 00:14:09,120
especially when the same files have changed.

334
00:14:09,120 --> 00:14:12,120
Once your local main is current, create a branch for your work.

335
00:14:12,120 --> 00:14:13,720
Keep the name clear and specific.

336
00:14:13,720 --> 00:14:15,720
If you are fixing a password reset link,

337
00:14:15,720 --> 00:14:19,920
a branch called FixPasswordResetLink tells the team exactly what it contains.

338
00:14:19,920 --> 00:14:21,920
A name like MercoWork tells them nothing.

339
00:14:21,920 --> 00:14:23,920
Then make the smallest useful change.

340
00:14:23,920 --> 00:14:26,120
Maybe the reset link points to the wrong page.

341
00:14:26,120 --> 00:14:29,920
You change that one part, test it, and check which files changed.

342
00:14:29,920 --> 00:14:32,120
If you also noticed a spelling error somewhere else,

343
00:14:32,120 --> 00:14:35,520
leave that for another branch, unless it belongs to the same fix.

344
00:14:35,520 --> 00:14:37,520
Small changes move through review faster.

345
00:14:37,520 --> 00:14:40,320
They are also easier to understand when something later goes wrong.

346
00:14:40,320 --> 00:14:42,720
If a commit says FixPasswordResetLink,

347
00:14:42,720 --> 00:14:44,320
everyone knows where to start looking.

348
00:14:44,320 --> 00:14:47,120
If it says many updates, nobody knows what happened.

349
00:14:47,120 --> 00:14:51,320
When the change is ready, select the files for the commit and write a useful message.

350
00:14:51,320 --> 00:14:55,520
A message like FixPasswordResetLink gives the next person a clear record.

351
00:14:55,520 --> 00:14:56,920
You don't need a novel.

352
00:14:56,920 --> 00:14:59,120
You need a short sentence that explains the work.

353
00:14:59,120 --> 00:15:02,320
After the commit is stored locally, push your branch to GitHub.

354
00:15:02,320 --> 00:15:03,720
Now your teammates can see it.

355
00:15:03,720 --> 00:15:05,720
The next step is to open a pull request.

356
00:15:05,720 --> 00:15:08,520
This gives the change a place for review before it joins main.

357
00:15:08,520 --> 00:15:10,320
A teammate might spot a missing test.

358
00:15:10,320 --> 00:15:12,320
Someone may ask why the link changed.

359
00:15:12,320 --> 00:15:15,520
An automated check may find that the page fails to build.

360
00:15:15,520 --> 00:15:17,120
That is the point of the process.

361
00:15:17,120 --> 00:15:20,920
Problems are cheaper to fix while the change is still small and separate from the shared version.

362
00:15:20,920 --> 00:15:24,320
You correct what needs correcting, make another commit and push again.

363
00:15:24,320 --> 00:15:26,120
The pull request updates with the new work.

364
00:15:26,120 --> 00:15:28,720
Once the review is approved and the automated checks pass,

365
00:15:28,720 --> 00:15:30,520
the branch merges into main.

366
00:15:30,520 --> 00:15:33,320
At that point main becomes the version the team agrees on.

367
00:15:33,320 --> 00:15:36,520
The branch has done its job, so teams often delete it after the merge.

368
00:15:36,520 --> 00:15:39,920
The history remains in Git, but the active list of branches stays tidy.

369
00:15:39,920 --> 00:15:42,520
This same flow can also start work behind the scenes.

370
00:15:42,520 --> 00:15:47,320
When a pull request opens, a connected service can automatically build the project and run tests.

371
00:15:47,320 --> 00:15:48,720
When the pull request merges,

372
00:15:48,720 --> 00:15:53,320
another process can prepare the software for release or send it to an environment where people can use it.

373
00:15:53,320 --> 00:15:55,320
You may hear this called CI/CD.

374
00:15:55,320 --> 00:15:59,920
Continuous integration means the team brings small changes together often and checks that they still work together.

375
00:15:59,920 --> 00:16:04,720
Continuous delivery or deployment means those check changes can move toward release with fewer manual steps.

376
00:16:04,720 --> 00:16:07,520
It doesn't perform every test or release the software by itself.

377
00:16:07,520 --> 00:16:10,320
It provides the agreed record that other tools react to.

378
00:16:10,320 --> 00:16:16,520
A push, a pull request or a merge can trigger those tools because Git identifies the exact version of the project they should check.

379
00:16:16,520 --> 00:16:18,920
AI now joins some parts of this workflow too.

380
00:16:18,920 --> 00:16:25,120
It can draft a commit message, write a short pull request summary, point out files that changed, or suggest a review comment.

381
00:16:25,120 --> 00:16:28,920
That can save time, especially on routine work, but AI doesn't own the decision.

382
00:16:28,920 --> 00:16:34,920
Someone on the team still needs to read the change, decide whether it belongs in the project and approve it before shared work moves forward.

383
00:16:34,920 --> 00:16:38,320
A clean-looking summary can't prove the code does the right thing.

384
00:16:38,320 --> 00:16:39,920
So the daily route is straightforward.

385
00:16:39,920 --> 00:16:44,920
Update from main, create a focused branch, make a focused change, commit it, push it and open a pull request.

386
00:16:44,920 --> 00:16:50,920
That routine turns a group of separate computers into one team that can move without losing track of what changed.

387
00:16:50,920 --> 00:16:56,920
Git records deliberate checkpoints in your project, while GitHub gives the team a shared place to review and combine them.

388
00:16:56,920 --> 00:16:58,320
Keep this route in mind.

389
00:16:58,320 --> 00:17:00,920
Work, stage, commit, push, review, merge.

390
00:17:00,920 --> 00:17:06,720
Subscribe on M365.fm for more knowledge nuggets that explain the tools behind modern work and play in English.

391
00:17:06,720 --> 00:17:10,320
And share this episode with someone who still thinks Git and GitHub are the same thing.