Version Control Fundamentals
Version control records changes to files over time so a team can inspect earlier versions, compare work, and combine concurrent edits. It uses a repository for history and a working copy for the files a person edits.
itComputer fundamentals | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Version Control Fundamentals
Version control is a system that records changes to files over time so a team can inspect an earlier state, compare two states, and combine concurrent work without silently overwriting either one. Before it existed, that job was done by renaming copies and hoping somebody remembered which one was current. The hope did not scale.
The useful picture has two places. The repository holds recorded history. The working copy is the editable local view of one selected state. Everything else — branches, merges, conflicts, remotes — is policy layered on that split. Most confusion at the start is treating the working copy as the repository, which is exactly the mistake the model exists to prevent.
A revision, often called a commit, records a deliberate change with enough metadata to place it in history. A good one has a narrow purpose. If a single revision changes authentication behavior and also reformats unrelated files, separating them is not tidiness; it is what makes later inspection, reversal, and bisect possible. The system preserves any collection of file changes. It cannot decide which collection communicates one coherent change. That is your job, and it is the one the tool will not do for you.
Collaboration introduces a coordination problem, and there are two topologies for solving it. A centralized system has one repository server; Subversion is the representative example. A distributed system gives each clone the full repository history; Git and Mercurial are the representatives. Distributed does not mean ungoverned. Teams still pick an authoritative remote and write integration rules. The topology changes where history lives. It does not replace policy.
When histories meet, the tool combines non-overlapping changes and stops when two edits could both be intended. That stop is a conflict, and it is a decision point rather than an error. Inspect both sides, choose the combined content the project actually needs, record the resolution, and test it. The surprising part is that this is the one moment the tool admits it cannot read your mind, which is considerably more useful than the alternative.
Read the Intro for the full model, Slides for the relationships at a glance, and the Cheatsheet for the decision rules. The quiz checks whether the vocabulary has stopped pretending to be interchangeable. Git Fundamentals is the next course once this model is clear and a concrete tool is wanted.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
Supports
- Version control records file changes over time and permits comparison and recall of earlier states
- Local, centralized, and distributed version-control models
- Distributed clones mirror repository history and can work with multiple remotes
- The foundation link rationale and centralized-versus-distributed quiz answers
- https://svnbook.red-bean.com/en/1.8/svn.basic.version-control-basics.html
Supports
- Repository and working-copy roles
- Historical questions, collaboration, and the risk of concurrent overwrite
- Lock-modify-unlock and copy-modify-merge models
- The Subversion study-path rationale and conflict, working-copy, and locking quiz answers
- https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
Supports
- Branching as divergence from the main line
- Git commits as snapshots with parent relationships and Git branches as pointers
- The branch study-path rationale and branch quiz answer
- https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
Supports
- Representative branching, merging, and conflict workflow
- The merging study-path rationale and conflict quiz answer
- https://www.mercurial-scm.org/guide
Supports
- Mercurial workflow examples for initialization, adding files, recording a changeset, and viewing history
- The Mercurial study-path rationale
- https://git-scm.com/book/en/v2/Getting-Started-What-is-Git
Supports
- Git's snapshot-oriented implementation, local operation, and file lifecycle
- The Git implementation study-path rationale
- https://git-lfs.com/
Supports
- Git LFS text pointers in Git and large file content stored on a remote server
- Large-file limits in Git examples, the Git LFS link rationale, and the large-file quiz answer
- The Git Large File Storage awesome-link rationale
- https://github.com/sindresorhus/awesome
Supports
- Discovery of the Git Add-ons awesome list as a curated source for Git ecosystem tools
- https://github.com/stevemao/awesome-git-addons
Supports
- Curation of Git Extras and diff-so-fancy as Git command-line add-ons
- The Git Extras and diff-so-fancy awesome-link selection
- https://github.com/tj/git-extras
Supports
- Git Extras utilities for repository summaries, changelog population, author statistics, and documented command examples
- The Git Extras awesome-link rationale
- https://github.com/so-fancy/diff-so-fancy
Supports
- diff-so-fancy human-readable Git diff output and Git pager or interactive-diff configuration
- The diff-so-fancy awesome-link rationale
- https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git
Supports
- BitKeeper license revocation in 2005 motivating Git creation
- Git begins for Linux kernel development in 2005
- The BitKeeper license withdrawal timeline event and the Git begins timeline event
- https://en.wikipedia.org/wiki/Concurrent_Versions_System
Supports
- CVS publicly released in 1986 by Dick Grune
- CVS 1.0 submitted to the FSF in November 1990
- The CVS 1986 release and CVS 1.0 1990 timeline events
- https://en.wikipedia.org/wiki/Apache_Subversion
Supports
- Subversion project begun by CollabNet in October 2000
- Subversion 1.0 released February 2004
- Subversion became an Apache top-level project February 2010
- The Subversion 2000, 2004, and 2010 timeline events
- https://en.wikipedia.org/wiki/Mercurial
Supports
- Mercurial announced April 2005 by Olivia Mackall
- BitKeeper license withdrawal as impetus for Mercurial
- The Mercurial announced April 2005 timeline event
- https://en.wikipedia.org/wiki/BitKeeper
Supports
- BitKeeper introduced a distributed version control system in 2000
- The BitKeeper 2000 distributed model timeline event
- https://github.com/git-lfs/git-lfs/releases/tag/v1.0.0
Supports
- Git LFS 1.0.0 released October 2015
- The Git LFS 1.0.0 2015 timeline event
- https://github.com/git/git/blob/master/Documentation/RelNotes/2.23.0.adoc
Supports
- Git 2.23 introduced git switch and git restore in August 2019
- The Git 2.23 2019 timeline event
- https://github.com/git/git/blob/master/Documentation/RelNotes/2.28.0.txt
Supports
- Git 2.28 made the initial branch name configurable in July 2020
- The Git 2.28 2020 timeline event
- https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/
Supports
- Recovery depended on surviving repository copies after a destructive change
- The GitLab 2017 outage field notes mistake card on destructive shared-history rewrites
- https://git-scm.com/
Supports
- Git as a distributed version control system product entry
- The Git product landscape entry
- https://www.mercurial-scm.org/
Supports
- Mercurial as a distributed version control system product entry
- The Mercurial product landscape entry
- https://subversion.apache.org/
Supports
- Apache Subversion as a centralized version control system product entry
- The Apache Subversion product landscape entry
- https://www.perforce.com/products/helix-core
Supports
- Perforce Helix Core as a centralized system for large binary assets
- The Perforce Helix Core product landscape entry
- https://github.com/
Supports
- GitHub as a hosted remote with review and integration policy
- The GitHub product landscape entry
- https://about.gitlab.com/
Supports
- GitLab as a hosted or self-managed remote with merge requests
- The GitLab product landscape entry
- https://bitbucket.org/
Supports
- Bitbucket as a hosted remote for shared history
- The Bitbucket product landscape entry
