Version Control (Git)
MIT 6.NULL The Missing Semester of Your CS Education, lecture 6, explained in plain English
Want this lecture to stick? In LessonBound you get checked practice questions for every part, can ask about anything you don't get, and can listen with your screen off. Free, no ads.
Learn this lecture freeWatch or read the original lecture: MIT OpenCourseWare.
Part 1
Git is a version control tool that saves your project as a history of snapshots, and it is built on a simple, understandable design.
Key ideas
- Version control tools save snapshots of a project so you can look back at old versions, see why changes were made, and work with others. Git stores each snapshot as a top-level folder, called a tree, that holds files (blobs) and other folders.
- Git's history is a graph of commits, and each commit points to its parent commits. A commit can have more than one parent when two lines of work are combined (merged).
- Every object in Git is identified by a SHA-1 hash, which is a long code made from its contents. Objects never change, but references are human-readable names, like master, that point to a commit and can be moved.
- The staging area lets you choose exactly which changes go into the next commit. This is how you can save a bugfix without saving your debugging print statements.
- The lecture teaches Git from the bottom up: first the data model, then the commands. Once you understand the data model, each command makes sense as a change to the commit graph.
Words to know
- blob
- Git's name for a single file. It is just a bunch of bytes, with no name inside it; the name is kept by the folder that holds it.
- DAG
- Short for directed acyclic graph. In plain terms, it is a set of connected steps that go one way and never loop back, like a family tree of commits.
- staging area
- A holding spot where you pick the changes you want in your next commit, so you can leave out the changes you do not want to save yet.
- reference
- A readable name, such as master or HEAD, that points to a commit. Unlike a commit, a reference can be moved to point to a new commit.
Example
Think of a commit like a saved photo of your whole project folder at one moment, with a note saying when and why it was taken. The staging area is like choosing which pages to put in a new photo album page before you save it, so you can leave out pages you are not ready to keep. A reference is like a sticky label saying 'latest' that you can move to point at a newer photo.
3 checked practice questions for this part are in the app.
Part 2
This part covers the Git commands for sharing work with others, undoing mistakes, and a few handy extras like stash and bisect.
Key ideas
- A remote is a copy of your project stored somewhere else. git push sends your work to that remote and updates the remote's record of where things are.
- git fetch downloads changes from a remote without changing your own files. git pull does the same thing as fetch and then merges the changes into your work.
- Git has ways to undo mistakes. git commit --amend edits your last commit, and git checkout -- throws away changes you have not saved in a commit.
- git stash temporarily sets aside your uncommitted changes so you can work on something else. git bisect uses a binary search through the history to find the change that caused a problem.
- Git and GitHub are not the same thing. Git is the tool, and GitHub is one website that hosts Git projects and has its own way of proposing changes, called pull requests.
Words to know
- remote
- a copy of a project stored on another computer or website, which you can send your work to or download from.
- commit
- a saved snapshot of your project at one point in time, with a message that describes what changed.
- stash
- a temporary shelf where Git keeps your unfinished changes so you can clear your work area and bring them back later.
- bisect
- to split something in half again and again to find one spot. Git uses this to search old versions for the change that caused a bug.
Example
Think of a shared notebook that a team passes around. Pushing is like adding your pages to the shared copy, and fetching is like checking what others have added without changing your own pages. Pulling is like fetching and then combining their new pages into your notebook.
3 checked practice questions for this part are in the app.
← Lecture 5: Command-line Environment · Lecture 7: Debugging and Profiling →
Notes written by AI (Claude) from the lecture's official transcript, so check anything important against the lecture. MIT CSAIL · CC BY-NC-SA 4.0 · not affiliated with or endorsed by MIT. These notes are shared under the same license.
LessonBound · Free lecture notes · Privacy · Terms · New York