openskills.info
Open Course

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

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