Orientation: why this chapter exists

1. The promise

You'll know why every engineering team on the planet uses Git, what you'll be able to do at the end of this chapter that you can't do now, and how this chapter fits into the rest of the course.

2. The mental model

Git is two machines in one. It's a time machine and a parallel-universe machine.

The time machine lets you go back to any past state of the code. Yesterday's working version. Last week's design. The state right before you broke everything.

The parallel-universe machine lets two versions of the project exist at once, then merge back together. You can try a redesign without losing the working version. Two people can edit the same project without overwriting each other.

Every other Git concept is detail on top of those two ideas.

(DIAGRAM: time machine plus parallel-universe machine — annotated SVG — left panel: linear timeline with arrows pointing to past commits; right panel: a branching graph showing two parallel timelines that merge)

You have a to-do app from Ch 7 sitting in a folder. You've edited it many times. Right now, you can't undo your changes from yesterday. You can't try a new design in parallel without copying the folder. You can't share it with anyone else without zipping it.

This chapter fixes all three problems with one tool.

Some quick terms before we start, so the rest of the chapter has clean ground to stand on.

• Version control is a system that keeps a history of every change to a set of files, so you can see who changed what, when, and why — and undo any of it.
• Git is the most widely used version-control program in the world. Free, open source, runs locally on your machine.
• GitHub is a website that hosts Git repositories on the internet so multiple people can collaborate.
• Repository (or repo) is one project tracked by Git. A folder of files plus its full history.

Every company you might want to work at uses Git. Most use GitHub or GitLab on top of it. Junior engineers are expected to use Git on day one. Not knowing it disqualifies the application.

(SCREENSHOT: the GitHub home page at github.com — full window — no highlights)

(SCREENSHOT: VSCode showing the to-do app folder from Ch 7 — Explorer sidebar visible — full window)

The shape of this chapter: command line first, GUI second. You'll type commands. You'll see what each one moves. You'll use the GitHub website only after you understand the local model. Students who learn the GitHub Desktop or VSCode source-control panel first can't debug Git when it breaks. Students who learn the command line can use any front-end on top of it.

(SCREENSHOT: a typical engineer's GitHub profile page — full window — contribution graph visible)

Honest time estimate: about six hours of guided study, plus an hour and a half for the assignment.

3. What changes by the end of the chapter

You'll have:

• Git installed and your name and email configured.
• A GitHub account with an SSH key linked to it.
• The Ch 7 to-do app pushed to a public GitHub repo.
• At least twelve real commits across at least one feature branch.
• A pull request opened on your own repo, with a real description.
• A .gitignore, a tagged release, and a git revert in your history.
• The recovery commands to get out of common mistakes without panic.

That's the assignment. Every unit between here and 8.17 builds one piece of it.

4. What you should be seeing

A clear picture in your head of two things:

1. Git solves four problems: history, attribution, collaboration, experimentation.
2. The chapter teaches Git on the command line first. GitHub comes in unit 8.12.

If you can say those two things without looking back, you're done with this unit.

5. Common stumbles

• You try to skip ahead to GitHub before understanding local Git. The website is a thin layer over the program. Skip the program and the website never makes sense.
• You open VSCode's source-control panel and try to learn Git by clicking. The panel is fine later. For now it hides the three trees you're about to learn. Type the commands first.
• You think "I work alone, I don't need version control." You will. You want history and experimentation even with no collaborators.

6. You should know