WEBVTT

1
00:00:00.000 --> 00:00:01.358
Recovery becomes manageable

2
00:00:01.381 --> 00:00:05.491
when you name the state and the content
you want to preserve. This lesson uses

3
00:00:05.538 --> 00:00:10.019
three separate disposable folders.
In one, we resolve a text conflict.

4
00:00:10.298 --> 00:00:13.154
In another, we discard one
unwanted uncommitted edit.

5
00:00:13.537 --> 00:00:17.345
In the third, we reverse a committed
fault while retaining history. Keeping

6
00:00:17.391 --> 00:00:21.002
these exercises separate prevents one
recovery operation from destroying

7
00:00:21.037 --> 00:00:24.938
another exercise's useful work.
The supplied history bundle

8
00:00:24.973 --> 00:00:29.245
contains generic manufactured teaching
commits and stable checkpoint tags.

9
00:00:29.628 --> 00:00:33.390
Clone it into a new conflict folder
and inspect the available branches.

10
00:00:33.773 --> 00:00:37.210
Create your working branch from
the prepared left conflict branch.

11
00:00:37.593 --> 00:00:40.100
Then merge the prepared
right conflict branch using

12
00:00:40.147 --> 00:00:42.596
the command sequence in
the written resources.

13
00:00:42.922 --> 00:00:46.463
Begin clean so that the example's
recovery path is understandable.

14
00:00:46.846 --> 00:00:50.096
Both branches changed the
same README report-label line.

15
00:00:50.480 --> 00:00:53.963
One describes teaching input
and the other generated input.

16
00:00:54.288 --> 00:00:59.210
Git cannot decide which wording you
intend, so the merge reports a conflict.

17
00:00:59.419 --> 00:01:03.820
That is a request for a content decision,
not proof that the repository is broken.

18
00:01:04.330 --> 00:01:07.314
Open the file and read the marked
sections with their labels.

19
00:01:07.639 --> 00:01:11.192
In this ordinary merge, the upper
contribution belongs to the current

20
00:01:11.250 --> 00:01:14.501
side and the lower contribution
to the branch being merged.

21
00:01:15.012 --> 00:01:19.180
Current does not mean correct. Read the
surrounding document and the requirement

22
00:01:19.215 --> 00:01:22.721
that all demonstration input
remain explicitly synthetic.

23
00:01:23.104 --> 00:01:25.357
The best resolution may be a new sentence

24
00:01:25.391 --> 00:01:28.097
that captures the useful
intent of both sides.

25
00:01:28.700 --> 00:01:33.565
Use the agreed sentence from the lesson:
Report label: synthetic teaching input.

26
00:01:33.890 --> 00:01:36.432
Remove the marker lines
and rejected duplicates.

27
00:01:36.758 --> 00:01:39.463
Preview the README and
read the whole paragraph.

28
00:01:39.788 --> 00:01:44.165
A control labeled accept both can
be convenient, but it cannot judge

29
00:01:44.188 --> 00:01:48.449
whether the result is coherent or whether
it loses the crucial origin label.

30
00:01:48.832 --> 00:01:53.825
Stage README to mark the path resolved,
then inspect the cached diff and status.

31
00:01:54.266 --> 00:01:57.006
Staging says the file is
ready to complete the merge;

32
00:01:57.180 --> 00:01:58.910
it does not certify its meaning.

33
00:01:59.188 --> 00:02:03.147
Commit the resolution with a descriptive
message and inspect the final state.

34
00:02:03.531 --> 00:02:07.420
Save the competing text and resulting
sentence in your exercise record.

35
00:02:07.699 --> 00:02:09.498
If you are not ready to resolve,

36
00:02:09.672 --> 00:02:13.376
abort the merge using the documented
command and inspect status.

37
00:02:13.701 --> 00:02:15.535
The clean starting state matters.

38
00:02:15.744 --> 00:02:19.343
An abort operation should not be
treated as a promise to reconstruct

39
00:02:19.413 --> 00:02:22.792
arbitrary unrelated edits
that existed before the merge.

40
00:02:23.117 --> 00:02:25.775
Preserve useful work
before entering a complex

41
00:02:25.857 --> 00:02:29.642
operation rather than expecting
recovery to guess your intentions.

42
00:02:30.025 --> 00:02:34.344
Now move to the separate restore
folder. Start a clean branch from CP01

43
00:02:34.785 --> 00:02:38.918
and make one harmless README edit that
you explicitly do not want to keep.

44
00:02:39.359 --> 00:02:42.784
Do not stage it. Inspect
the path-specific diff.

45
00:02:43.063 --> 00:02:46.256
Before running restore, explain
which content will be lost

46
00:02:46.302 --> 00:02:49.448
and confirm that nothing useful
is mixed into that file edit.

47
00:02:49.889 --> 00:02:54.058
Working-tree restore replaces the
selected file from the index by default.

48
00:02:54.383 --> 00:02:57.436
In this prepared example,
the index matches the baseline

49
00:02:57.471 --> 00:03:00.629
commit because we began clean
and did not stage anything.

50
00:03:00.908 --> 00:03:03.392
The command discards the
unwanted working edit.

51
00:03:03.671 --> 00:03:07.642
Inspect the file and diff afterward
to confirm the actual result.

52
00:03:07.967 --> 00:03:10.835
This differs from restore
with the staged option.

53
00:03:11.160 --> 00:03:14.573
The staged option changes the
selected snapshot while preserving

54
00:03:14.631 --> 00:03:17.452
working content, as we practiced
in the previous module.

55
00:03:17.731 --> 00:03:21.435
The same command family can affect
different places depending on its options.

56
00:03:21.818 --> 00:03:27.124
Name the target state before you act:
working tree, staging area, or history.

57
00:03:27.565 --> 00:03:29.028
For the third exercise,

58
00:03:29.237 --> 00:03:33.451
use another clone and create a branch
from the supplied FAULT-hysteresis tag.

59
00:03:33.892 --> 00:03:38.293
This is a prepared later-project example
used only to practice Git recovery.

60
00:03:38.618 --> 00:03:42.635
It contains the full tests needed
to show an isolated bad comparison.

61
00:03:42.960 --> 00:03:46.397
You are not being asked to implement
the capstone now or understand

62
00:03:46.489 --> 00:03:49.357
every later policy
feature before continuing.

63
00:03:49.682 --> 00:03:54.303
Inspect the current commit and verify
that HEAD is the isolated seeded fault.

64
00:03:54.581 --> 00:03:58.854
The defect uses a strict comparison that
misses clearing at exactly twenty-seven

65
00:03:58.889 --> 00:04:02.395
degrees Celsius. That is different
from the introductory warning-entry

66
00:04:02.453 --> 00:04:06.458
boundary at twenty-eight. Read the
supplied expected case and run the native

67
00:04:06.493 --> 00:04:10.197
tests to observe the specific
failure before attempting recovery.

68
00:04:10.800 --> 00:04:14.005
Run revert with no-edit on
that verified HEAD commit.

69
00:04:14.516 --> 00:04:17.813
Revert creates a new commit that
reverses the selected change.

70
00:04:18.138 --> 00:04:22.468
The original fault remains visible in
history, followed by a corrective event.

71
00:04:22.747 --> 00:04:25.719
This is useful for shared work
because earlier references

72
00:04:25.765 --> 00:04:28.343
are preserved rather
than silently rewritten.

73
00:04:28.854 --> 00:04:31.872
In more complex history,
a revert can conflict;

74
00:04:32.255 --> 00:04:35.703
our isolated exercise keeps
the basic operation clear.

75
00:04:36.214 --> 00:04:39.883
Rerun the same native test command
and the documented firmware build.

76
00:04:40.208 --> 00:04:41.914
Save the actual results.

77
00:04:42.123 --> 00:04:45.571
The expected recovery is a failing
boundary check before the revert

78
00:04:45.606 --> 00:04:49.043
and passing checks afterward, with
a new revert commit in the log.

79
00:04:49.287 --> 00:04:51.028
These are software observations.

80
00:04:51.272 --> 00:04:54.964
They do not show a physical sensor
or alarm operating on a board.

81
00:04:55.289 --> 00:04:58.668
Write one short record for
each folder: starting state,

82
00:04:58.911 --> 00:05:02.696
useful data to preserve, chosen
operation, and observed result.

83
00:05:03.079 --> 00:05:05.784
For the conflict, preserve
both useful meanings.

84
00:05:06.109 --> 00:05:10.010
For restore, discard only the
unwanted uncommitted edit.

85
00:05:10.451 --> 00:05:14.271
For revert, preserve history while
reversing the isolated fault.

86
00:05:14.596 --> 00:05:17.301
If your record cannot explain
that distinction, repeat

87
00:05:17.348 --> 00:05:19.902
the relevant disposable
example before proceeding.

88
00:05:20.285 --> 00:05:23.408
The three folders also help
you compare evidence afterward.

89
00:05:23.791 --> 00:05:25.068
In the restore example,

90
00:05:25.347 --> 00:05:29.631
no new corrective commit is expected
because you discarded an uncommitted edit.

91
00:05:29.956 --> 00:05:34.611
In the revert example, a new commit is the
expected evidence of historical reversal.

92
00:05:35.053 --> 00:05:36.516
In the conflict example,

93
00:05:36.841 --> 00:05:40.486
the merged content and completed
merge record both matter.

94
00:05:41.090 --> 00:05:42.901
If all three notebooks simply say

95
00:05:42.971 --> 00:05:46.605
clean, they omit the distinctions
this lesson is designed to teach.

96
00:05:47.116 --> 00:05:51.794
Record the operation's actual effect,
not just its final quiet state.

97
00:05:52.236 --> 00:05:53.930
You are ready for the final module

98
00:05:53.977 --> 00:05:57.796
challenge when each recovery has a
concrete purpose and verified outcome.

99
00:05:58.493 --> 00:06:01.012
A quiet status display is
not enough if the requested

100
00:06:01.047 --> 00:06:02.940
improvement disappeared with the mistake.

101
00:06:03.636 --> 00:06:07.038
Compare the final content and behavior
with the original requirement,

102
00:06:07.316 --> 00:06:10.683
and keep the evidence that lets
another person follow your decision.