2.1 Purpose and Benefits of Version Control
Key Takeaways
- A version control system (VCS) records which changes were made, who made them, when they happened, and why, and can recover any earlier snapshot of a project.
- Git is a distributed VCS: every clone holds the full project history and does not need a constant connection to a central server to commit, branch, or inspect log.
- git log (GitHub Commits) shows the timeline of snapshots; git blame (GitHub Blame) attributes the last change to each line so you can find context, not assign guilt.
- git revert adds a new commit that undoes an earlier commit and is the collaboration-safe undo on a shared branch; rewriting history changes commit SHAs and is unsafe on branches other people already pulled.
A version control system (VCS) records how a project's files change over time so any earlier snapshot can be recovered, compared, or branched. GitHub Docs frames the job of a VCS in four questions: which changes were made, who made them, when they happened, and why they were needed. That timeline is the foundation of GitHub Foundations Domain 1 (Understand Git and GitHub basics, 25–30%). GitHub Issues, pull requests, and Actions sit on top of version control. They do not replace it.
Why GH-900 starts here
Candidates often arrive at GH-900 from the GitHub website: they have opened a repository, clicked History, or merged a pull request. The exam still asks you to describe version control before those product features. If two people edit the same file, if last week's build is the one that still works, or if a reviewer needs to know who changed a production script, a shared drive named final-v3-REALLY-FINAL.zip cannot answer. A VCS can. GitHub's collaboration layer is valuable, but it assumes there is already a reliable history of snapshots. If you cannot reconstruct last Tuesday's code, a pull request cannot review it and an Action cannot test it.
GH-900 trap: an answer that says "GitHub hosts websites" or "GitHub runs Actions" is describing the platform, not the purpose of version control. Prefer the answer that names history, parallel work, recovery, and inspection.
Why teams adopt a VCS before GitHub features
A team can store files in email attachments, a network share, or a cloud folder with "track changes" turned on. Those habits fail as soon as two people edit the same file at the same time, a bug appears in last week's build, or an auditor asks who changed a production script. A VCS gives every contributor a unified view of the project and of work already in progress. Seeing a transparent history of changes, who made them, and how they contribute to the project keeps people aligned while they work independently.
Git is a distributed version control system (DVCS). Every clone is a full copy of the project and its history. You do not need a constant connection to a central server to commit, create a branch, or run git log. Older centralized systems such as CVS and Subversion stored the canonical history on one server; offline work was limited and the server was a single point of failure. GH-900 does not ask you to administer Subversion, but it does expect you to know why Git's distributed model is the default for both open source and commercial software: people work across time zones, keep source integrity, and still share a single timeline of decisions.
In practice: the shared-drive failure
Imagine a documentation team that keeps policy.docx on a shared drive. Alex saves a rewrite at 10:00. Blair saves a different rewrite at 10:05 and overwrites Alex. There is no git log, no way to merge both edits, and no way to recover Alex's 10:00 file unless the drive has an unrelated backup. A VCS would have given each person a snapshot, a way to merge, and a blame line showing who last touched each paragraph. GitHub Issues could then discuss the policy change, but only after the VCS made the two versions comparable.
History as snapshots, not a pile of diffs
Git stores commits as snapshots of the project, not as a stack of "changeset" patches the way some older tools did. Each commit points at a tree of files and at one or more parent commits. Together those commits form a directed acyclic graph (DAG): you can walk backward through history, but you cannot loop. That graph is what git log prints and what GitHub's Commits tab displays.
Because history is a graph of snapshots, you can:
- Recover any earlier version of a file or of the whole project
- Compare two commits to see what changed
- Branch to try an idea without touching the default line of development
- Merge (or rebase) when the idea is ready
A commit is cheap. GitHub flow guidance even recommends putting an isolated, complete change in each commit so you can revert one idea without dragging another idea with it. If you rename a variable and add tests in the same commit, undoing the rename later also undoes the tests. Split them, and git revert can cancel only the rename.
Collaboration, blame, and log
A VCS is a collaboration tool even when nobody is using GitHub yet. Two developers can work independently, then combine histories. git log answers what changed and when. git blame (and GitHub's Blame view) answers who last touched this line. Those two commands are how teams debug a production incident: you do not guess; you inspect the timeline.
On GitHub, the same ideas appear in the UI. The Commits tab is git log. Opening a file and choosing Blame is git blame. A pull request conversation is extra collaboration on top of those Git facts.
GH-900 trap: blaming a coworker with git blame is not the point of the command. The command attributes the last change to a line so you can ask the person who has context, or so you can find the commit that introduced a regression. An exam stem that treats blame as a performance-review tool is a distractor.
| Inspection | Git command | GitHub UI | Question it answers |
|---|---|---|---|
| Timeline of snapshots | git log | Commits tab | What changed, when, and with which message? |
| Line attribution | git blame | Blame view | Who last changed this line, in which commit? |
| File or commit comparison | git diff | Files changed / compare | What is different between two snapshots? |
| Recover an earlier file | git checkout / git restore | History → view file at commit | What did this file look like last Tuesday? |
Revert versus rewrite
This distinction is exam-critical. "Undo" is not one operation.
| Action | What it does to history | Typical commands | Safe on a shared default branch? |
|---|---|---|---|
| Revert | Adds a new commit that undoes an earlier commit | git revert | Yes. History stays append-only. |
| Rewrite | Replaces commits, changing their SHAs | git rebase, git commit --amend, git reset plus force-push | No, unless the branch is yours alone. |
Revert is how you undo a merged production bug without pretending the bug never existed. The bad commit remains in the log; a later commit cancels it. Auditors, teammates, and git blame can still see what happened. GitHub's "Revert" button on a pull request does the same thing: it opens a new pull request whose commits undo the merge.
Rewrite is how you tidy a local feature branch before you share it: squash "wip" commits, reorder, or drop a mistaken file. Because a rewritten commit has a new SHA, anyone else who based work on the old SHA will diverge. Force-pushing a rewritten main is how teams lose work. GitHub branch protection exists in part to block that class of mistake.
GH-900 trap: git revert and git reset --hard both undo work. Only revert is the collaboration-safe undo on a branch other people already pulled. reset --hard moves the branch pointer backward and can discard commits from the working copy. Combined with git push --force, it rewrites the remote. That is not "just undo" — it is history surgery.
Scenario: a bad merge on main
Priya's pull request merged a config change that broke production. The team needs main healthy again and a record of the incident.
- Correct: revert the merge (GitHub Revert, or
git revert -m 1 <merge-sha>).maingains a new commit.git logstill shows the original merge and the revert. An Action can re-run tests on the new tip. - Incorrect:
git reset --hardto the commit before Priya's merge, then force-pushmain. Everyone who already pulled the merge now has a divergent history. Blame, open pull requests, and deployed SHAs no longer match.
What version control is not
Version control is not a backup product by itself (though clones do spread copies). It is not project management (that is Issues, Projects, milestones). It is not CI (that is Actions). It is not a wiki. Teams use a VCS first because every later GitHub feature — pull requests that compare commits, Actions that run against a SHA, Codespaces that check out a repository, Dependabot that opens a branch — assumes a history of snapshots already exists.
On the exam, when a stem asks for the purpose of version control, pick history, collaboration, inspection, and recovery. When a stem asks how GitHub uses that history, you may then name pull requests and Actions. Do not collapse the two layers.
A GH-900 stem asks for the primary purpose of a version control system. Which statement is the best answer?
A teammate's commit landed on the shared default branch and broke production. The team wants to undo that change without pretending the bad commit never existed. Which approach matches Git's collaboration-safe undo?
During an incident, a reviewer needs to know who last changed a specific line in a production file and which commit introduced that line. Which pair of Git capabilities answers those two questions?