Version Control with Git
The problem
Software changes constantly, often with multiple people editing the same codebase at once, and without a system for tracking every change, who made it, and how changes combine, code either gets silently overwritten or requires manually emailing files back and forth to avoid conflict.
Why now
Graph theory already established the DAG (directed, acyclic graph) as the shape of any valid dependency or history structure; a Git repository's commit history is exactly that — each commit points to its parent(s), forming a DAG where merging is joining two branches of history back together, not a special case bolted on top.
Mental model
A Git commit is a node with one or more parent pointers, and the entire history is a DAG exactly like the ones graph-theory-basics covered — a branch is just a movable pointer to a commit, and a merge is creating a new commit with two parents, joining two previously separate paths through that graph back into one.
Requires
- Graph Theory BasicsMathematical Thinking
A Git repository's history is literally a directed acyclic graph of commits; branching, merging, and rebasing are all graph operations (adding nodes, joining paths, rewriting edges) on the exact structure already covered.
- The Shell & Filesystem NavigationLinux
Git is operated almost entirely from the shell, against files on the filesystem tree already covered; you need that comfort level before Git commands have a concrete substrate to act on.
Unlocks
Used in
- Every collaborative software project's history and change tracking
- Pull requests and code review, built entirely on Git's branching model
- CI/CD pipelines, triggered by commits and branches
- git bisect, which uses binary search over the commit DAG to find exactly which change introduced a bug
Projects
- Create a repository, make several commits on a branch, merge it into main, and resolve a deliberately introduced merge conflict
- Use git bisect to find which of 20 commits introduced a bug in a small test repository, and explain how the search uses binary search over the commit history
Examples
- A merge commit having two parents is directly visible with git log --graph, showing the DAG structure explicitly
- git bisect performs a binary search over commit history, needing only ~log₂(20) ≈ 5 tests to find the culprit among 20 commits
Resources
Mastery checklist
- I can explain a Git repository's history as a DAG of commits
- I can create branches, merge them, and resolve a merge conflict
- I can use git bisect to find a bug-introducing commit
- I can explain the difference between a merge and a rebase in terms of the resulting commit graph