Section 0.3: Version Control with Git
Work that exists in one state, on one machine, at one moment, is work you can destroy by editing it. Version control removes that risk by making history a thing you keep rather than a thing you overwrite: a repository records deliberate snapshots of a working tree, and those snapshots can be read, compared, undone, branched into parallel lines of work, and moved between machines. This section is where "my latest version" stops being whatever is on disk right now and becomes something you can name, inspect and return to.
Everything before this section lived in a single present tense. Section 2 could operate a workspace and supervise a run, but it could not tell you what that workspace looked like yesterday, or let you try a change knowing the previous state is recoverable. That is the gap here, and it is the last one Module 0 has to close.
Lessons
- Why Version Control Exists and How a Repository Works - the working tree, the staging area and the commit, and what each one actually holds.
- Reading History - Logs, Diffs, and Undoing - inspecting what changed and when, and returning to a previous state on purpose.
- Branching, Merging, and Resolving Conflicts - keeping parallel lines of work, bringing them back together, and settling the overlaps by hand.
- Collaborating - Remotes, Clone, Push, and Pull - moving a whole history between machines.
This is the last section of Module 0, and its skill is the one that keeps your work safe from here on: committing it and moving its history between machines.
By the end you will be able to:
- Turn an existing directory into a repository and commit its state deliberately.
- Read a history and say exactly what changed between any two points in it.
- Recover a file from any earlier commit, and back out of a merge you did not mean to finish.
- Merge two branches and resolve a conflict without discarding either side's work.
- Publish a repository to GitHub over SSH and keep two copies in step with push and pull.