Version Control, Snapshots, and Collaboration
Version control is not a folder that happens to contain old files. It is a model of complete project states connected by ancestry. Once you can read that model, branches become divergence, merges become integration, and collaboration stops looking like a sequence of mysterious buttons.
Four ideas hold the model together
What version control actually controls
A version control system manages selected project files and the relationships among recorded states. It gives each state identity, connects it to earlier states, and lets people compare, restore, and combine work. It does not automatically understand whether the code is correct. It preserves evidence so humans and tools can judge that question.
The word version is easy to misread. A version is not necessarily a release such as 2.4.0. During development, every meaningful recorded state can be a version. Most never become a public release; they still matter because they show how the project reached its current form.
Selected scope
The repository records files you choose to track. Downloads, secrets, build output, and the rest of the machine are separate concerns.
Stable identity
A recorded state has an identifier independent of filenames such as final-v3.
Ancestry
A state normally names one or more parents, so history is a graph rather than a bag of copies.
Reviewable difference
The system can derive what changed between complete states without pretending the difference is the whole state.
Snapshots are complete states, not loose patches
Suppose snapshot B changes only header.css. B still describes the README, source files, images, and every other tracked path. Conceptually, B is the complete project. Internally, Git can reuse unchanged file objects instead of copying identical bytes. That is an efficiency detail, not a different mental model.
A ──▶ B ──▶ C
parent parent
A Initial project
B Add navigation
C Fix mobile layoutIn this line, C names B as its parent and B names A. The arrows describe ancestry, not time alone. Two snapshots could be created minutes apart and still belong to different lines of work if they name different parents.
Test what you learned
What word names the earlier snapshot from which a new commit was created?
History is a graph, not a stack of folders
A straight line is only the simplest graph. Collaboration produces siblings: two people can start from B and each record a different next state. Neither D nor E is automatically wrong. They preserve two valid continuations of the same history.
D Add search
/
A ──▶ B
\
E Redesign header
D and E share B as their last common snapshot.B is the common ancestor. To integrate D and E, a tool compares B→D and B→E. If one side adds a file while the other edits a different file, the changes may combine automatically. If both make incompatible edits to the same place, a person must decide the intended result. That later decision becomes a new snapshot.
Centralized and distributed version control
One primary history service
- Developers check work into a central server.
- Server availability may be required for history operations.
- The central repository is the authoritative record.
- Working copies may contain less history locally.
Each clone carries history
- A normal Git clone includes repository history.
- Commits, comparisons, and branches work locally.
- A shared server is a coordination choice, not Git’s engine.
- Several repositories can exchange the same commits.
Distributed does not mean “everyone works alone” or “there is no main repository.” Teams commonly agree that a GitHub repository is the shared meeting place. The architectural point is that the local clone remains a real repository capable of recording and reading history without asking GitHub for permission.
Collaboration is movement through the graph
- 01Share a base
People begin from a known snapshot, so later differences have a common reference.
- 02Record independently
Each person makes one or more snapshots whose parent identifies where their work began.
- 03Compare decisions
Review examines what each line changed relative to the shared base.
- 04Integrate deliberately
A merge or replay creates an agreed continuation without erasing the evidence.
This model scales from one learner on a laptop to a large team. A solo developer still diverges when experimenting on a branch. A team still needs a human decision when two technically valid changes express incompatible product choices.
Worked example: two edits, one shared base
At B, a site has a navigation bar and a blank search area. Noor records D, which implements search. Eli records E, which renames navigation labels. Because both started from B, the review can isolate each decision. If they touched separate lines, the integrated state F can include both. If each renamed the same label differently, F requires a product decision.
B → D
Add the search form and keyboard label. The search decision is reviewable against the shared base.
B → E
Rename “Learn” to “Courses.” The navigation decision is reviewable against the same base.
D + E → F
Combine both when compatible. F records the reviewed result and points back to the integrated history.
If both edit one label
Stop and choose the intended wording. Version control identifies the conflict; it cannot own the product decision.
Test what you learned
What two-word phrase describes B when D and E both descend from it?
Independent lab: draw the collaboration graph
On paper, draw snapshots A→B→C for a three-step project. From B, draw a second child D. Give C and D different change messages. Then add E as an integrated result. Under the graph, answer:
- Which snapshot is the common ancestor of C and D?
- Which two comparisons reveal the independent work?
- What decision would require a person rather than automatic combination?
- Why is E a complete project state rather than a bag of two patches?
Common mistakes to remove now
“A commit is a diff.”
A commit identifies a snapshot and its parent. A diff is derived by comparing states.
“Distributed means no shared server.”
Teams can coordinate through GitHub while every clone remains a local repository.
“Branches duplicate the project.”
Branches will be movable names for graph positions, not copied project folders.
“Conflicts mean Git failed.”
Git correctly refuses to invent intent when independent decisions cannot combine safely.
Lesson review
A version control system records complete selected project states and their ancestry. Git’s distributed design gives each clone real local history. Parent links form a graph; siblings reveal divergence; a common ancestor provides the baseline for integration. Diffs explain change between snapshots, while conflicts expose decisions that automation cannot safely make.
- I can explain why a snapshot is complete even when most files are unchanged.
- I can read parent and child relationships in a simple history graph.
- I can distinguish centralized coordination from Git’s distributed repository model.
- I can find the common ancestor of two divergent lines of work.
- I can explain why a conflict requires intent rather than a more aggressive automatic guess.