WEBVTT

1
00:00:00.000 --> 00:00:02.032
We have inspected a small README edit.

2
00:00:02.357 --> 00:00:06.049
Now we will select that exact content
and record it as a useful commit.

3
00:00:06.374 --> 00:00:10.309
The important idea is that staging
and committing are separate actions.

4
00:00:10.693 --> 00:00:13.456
Staging chooses what belongs
in the next snapshot.

5
00:00:13.700 --> 00:00:17.705
Committing records that selected snapshot
with a message and its place in history.

6
00:00:18.146 --> 00:00:22.349
Start in the same CP01 practice
repository from the previous lesson.

7
00:00:22.674 --> 00:00:25.181
Confirm the current
folder and run Git status.

8
00:00:25.506 --> 00:00:29.686
The intended README change should still
be visible. Inspect the ordinary diff

9
00:00:29.732 --> 00:00:33.482
again so that the content you remember
matches the content currently on disk.

10
00:00:33.808 --> 00:00:37.964
If another edit appeared since the last
lesson, account for it before proceeding.

11
00:00:38.405 --> 00:00:39.752
Check the baseline history.

12
00:00:39.961 --> 00:00:43.793
The first commit records the reviewed
project source and build instructions.

13
00:00:44.118 --> 00:00:46.939
Our next commit will clarify
the synthetic input label.

14
00:00:47.322 --> 00:00:50.492
Two purposeful commits are easier
to understand than a single

15
00:00:50.538 --> 00:00:53.406
vague record containing
setup, generated output,

16
00:00:53.498 --> 00:00:56.970
experimental code, and wording
changes all mixed together.

17
00:00:57.666 --> 00:01:01.451
Before committing, make sure
repository-local identity is configured.

18
00:01:01.892 --> 00:01:04.841
Use your chosen author name
and the exact no-reply address

19
00:01:04.888 --> 00:01:08.011
shown in your GitHub settings
if you want that privacy option.

20
00:01:08.963 --> 00:01:13.491
These settings describe authorship. They
do not authenticate a push to GitHub.

21
00:01:13.932 --> 00:01:15.987
Keep private addresses out of screenshots

22
00:01:16.022 --> 00:01:19.076
and do not copy the instructor's
identity into your own work.

23
00:01:19.459 --> 00:01:23.232
Stage the exact README path
using Git add README dot md,

24
00:01:23.476 --> 00:01:25.624
or the file's stage control in the editor.

25
00:01:26.227 --> 00:01:28.050
Read the result in Source Control.

26
00:01:28.433 --> 00:01:33.263
The file now appears under Staged Changes.
That is a selection for the next commit,

27
00:01:33.379 --> 00:01:37.141
not a statement that the file is correct.
You are responsible for checking

28
00:01:37.176 --> 00:01:41.576
the content selected. Run the
ordinary diff and the cached diff.

29
00:01:41.785 --> 00:01:44.096
The ordinary comparison
should no longer show

30
00:01:44.165 --> 00:01:46.928
the label edit if the
working file matches staging.

31
00:01:47.253 --> 00:01:50.400
The cached comparison should show
it against the baseline commit.

32
00:01:50.725 --> 00:01:52.872
Read the removed and added lines again.

33
00:01:53.256 --> 00:01:56.855
This is the final concrete artifact
you are choosing to preserve.

34
00:01:57.180 --> 00:02:00.802
Notice why we stage a named file
instead of adding everything by habit.

35
00:02:01.046 --> 00:02:05.063
The project can contain temporary notes
or generated output that do not belong

36
00:02:05.098 --> 00:02:09.045
with this change. A broad selection
might be appropriate after a complete

37
00:02:09.080 --> 00:02:12.296
review, but it should follow that
review rather than replace it.

38
00:02:12.575 --> 00:02:16.243
Here one named README gives
us a clear, small boundary.

39
00:02:16.627 --> 00:02:18.542
Write a commit message around purpose.

40
00:02:18.983 --> 00:02:23.151
Clarify synthetic input in the report
label explains why the line changed.

41
00:02:23.535 --> 00:02:28.248
Messages such as update, fix stuff,
or AI changes leave the next reader

42
00:02:28.306 --> 00:02:32.033
guessing. The assistant's involvement
is not the behavior of the project.

43
00:02:32.358 --> 00:02:35.342
History is more useful when it
tells us what problem changed

44
00:02:35.400 --> 00:02:37.280
and what the resulting artifact does.

45
00:02:37.977 --> 00:02:39.927
Run the commit command from the lesson.

46
00:02:40.171 --> 00:02:43.143
Inspect its actual result,
then run the short history

47
00:02:43.201 --> 00:02:46.719
command. You should see the new label
commit followed by the baseline.

48
00:02:47.102 --> 00:02:50.330
Your identifiers and timestamps
will differ from the video's.

49
00:02:50.771 --> 00:02:54.475
That is expected because commit
metadata contributes to the identifier.

50
00:02:54.916 --> 00:02:58.910
Do not try to reproduce the instructor's
hash by changing your identity or clock.

51
00:02:59.235 --> 00:03:03.090
Run Git status again. A clean
state means the relevant tracked

52
00:03:03.136 --> 00:03:06.758
states agree and no ordinary
untracked candidates are listed.

53
00:03:07.142 --> 00:03:10.149
It does not prove a host check
or firmware build passed.

54
00:03:10.474 --> 00:03:14.119
Our change is a wording edit, so
we inspected its meaning directly.

55
00:03:14.398 --> 00:03:16.244
If you later commit source behavior,

56
00:03:16.418 --> 00:03:19.854
preserve the relevant command
results alongside the source version.

57
00:03:20.458 --> 00:03:23.535
Now we will explore a state
that often confuses beginners.

58
00:03:23.918 --> 00:03:27.691
After the label commit, make a harmless
new README sentence and stage it.

59
00:03:27.935 --> 00:03:31.093
Then edit that sentence again
without staging a second time.

60
00:03:31.371 --> 00:03:35.121
The editor may show the same
file as both staged and unstaged.

61
00:03:35.446 --> 00:03:36.816
That is not a contradiction:

62
00:03:37.142 --> 00:03:40.462
the staging area and working
tree contain different snapshots.

63
00:03:40.845 --> 00:03:45.756
Inspect both diffs. The cached view shows
the version selected when you ran add.

64
00:03:46.081 --> 00:03:50.435
The ordinary view shows the later change
relative to that selected version.

65
00:03:50.760 --> 00:03:53.929
If you committed now, Git would
record the staged content.

66
00:03:54.138 --> 00:03:57.969
It would not automatically choose the
latest text visible in the editor just

67
00:03:58.004 --> 00:04:01.638
because the file name is the same.
Decide which version you want.

68
00:04:01.963 --> 00:04:04.657
If both edits belong in
one meaningful change,

69
00:04:04.982 --> 00:04:07.896
save the final text and
stage it again after review.

70
00:04:08.337 --> 00:04:10.381
If the later edit is only an experiment,

71
00:04:10.706 --> 00:04:14.838
preserve anything useful and return the
file deliberately to the chosen version.

72
00:04:15.279 --> 00:04:18.252
Do not discard content
simply to make status quiet

73
00:04:18.461 --> 00:04:21.142
before understanding what
each snapshot contains.

74
00:04:21.653 --> 00:04:25.287
This mechanism is valuable when
used intentionally. You can keep

75
00:04:25.357 --> 00:04:28.886
work in progress while selecting a
coherent improvement for history.

76
00:04:29.327 --> 00:04:32.288
For now, prefer simple
file-level boundaries.

77
00:04:32.729 --> 00:04:36.433
Later, individual hunks can
help separate overlapping edits,

78
00:04:36.676 --> 00:04:41.587
but the underlying idea stays the same:
the next commit contains selected content,

79
00:04:41.831 --> 00:04:44.536
not an uncontrolled copy
of every current thought.

80
00:04:44.919 --> 00:04:48.333
Your exercise submission includes
the two latest history entries,

81
00:04:48.507 --> 00:04:52.384
a summary of the current commit, and an
explanation of the staging experiment.

82
00:04:53.081 --> 00:04:57.040
Another person should be able to connect
the message with the actual diff. If

83
00:04:57.075 --> 00:04:59.350
they cannot tell what
the commit does, improve

84
00:04:59.373 --> 00:05:01.754
the explanation or split
unrelated work before

85
00:05:01.800 --> 00:05:05.898
proceeding. You can inspect the current
commit with Git show after recording it.

86
00:05:06.281 --> 00:05:10.635
That comparison is a useful final check
that the snapshot matches your intention.

87
00:05:11.146 --> 00:05:15.047
If it contains less than expected,
you may have left an edit unstaged.

88
00:05:15.430 --> 00:05:19.389
If it contains more, review how the
selection was made before continuing.

89
00:05:19.714 --> 00:05:23.557
Do not assume a good commit message
repairs the wrong content. The message

90
00:05:23.581 --> 00:05:28.073
and snapshot need to agree, and the next
operation should follow the actual state.

91
00:05:28.456 --> 00:05:33.135
We have now built the basic local cycle:
inspect state, review the change,

92
00:05:33.344 --> 00:05:37.593
select content, review the selected
snapshot, and commit a meaningful unit.

93
00:05:38.035 --> 00:05:41.936
Nothing has been uploaded. In the next
challenge we will deliberately stage

94
00:05:41.994 --> 00:05:45.860
harmless generated output and recover
without deleting useful files.

95
00:05:46.556 --> 00:05:49.912
After that, the GitHub module
will add a carefully verified

96
00:05:49.970 --> 00:05:52.849
remote copy and a
second-checkout reproduction.