Version Control

⏱ 7 min✏️ Quiz at the end

What is Version Control?

When you write an essay you might save different drafts: essay_v1.docx, essay_final.docx, essay_FINAL2.docx. Programmers face the same problem with code, only worse β€” projects can have hundreds of files and dozens of contributors all changing things at once.

Version control is a system that tracks every change made to a set of files over time. Rather than saving copies manually, a version control tool records each revision automatically. You can see the full history of a project, see exactly what changed and who changed it, and go back to any earlier state at any time.

The most widely used version control system today is Git, created by Linus Torvalds in 2005. Platforms like GitHub and GitLab host Git repositories online so teams can collaborate from anywhere.

Core Concepts

Repository

A repository (often shortened to repo) is the folder where Git tracks your project. It contains all the project files plus a hidden .git folder that stores the entire history of every change ever made. You can have a local repository on your own computer and a remote repository on a server like GitHub.

Commit

A commit is a saved snapshot of the project at a specific moment. Think of it like a photograph β€” it captures exactly what every tracked file looked like at that instant. Each commit has:

  • A unique identifier (a long string of letters and numbers called a hash)
  • A commit message describing what changed
  • The author's name and the timestamp
  • A link to the previous commit, forming a chain back through history

You choose when to commit. Good practice is to commit whenever you complete a small, meaningful piece of work β€” not so rarely that one commit contains dozens of unrelated changes, and not so often that each commit is trivial.

Branch

A branch is an independent line of development. When you create a branch, you get your own copy of the project history to work on. Changes you make in your branch do not affect anyone else's work.

The default branch is usually called main (or historically master). Developers typically create a new branch for each new feature or bug fix:

main  ──●──●──●──────────────●  (stable, working code)
              β””β”€β”€β—β”€β”€β—β”€β”€β—β”€β”€β”˜
                  feature branch

Once the feature is tested and ready, the branch is merged back into main.

Merge

Merging combines the changes from one branch into another. Git compares the two branches and integrates the differences. Most of the time this works automatically. When two people have edited the same part of the same file in different ways, Git cannot decide which version to keep β€” this is called a merge conflict, and a developer must resolve it manually by choosing which changes to keep.

Push and Pull

When working with a remote repository (on GitHub, for example):

  • Push uploads your local commits to the remote server so others can see your work.
  • Pull downloads changes from the remote server that others have pushed, updating your local copy.

This push/pull cycle is how distributed teams stay in sync without overwriting each other's work.

A Typical Workflow

  1. Clone the remote repository to create a local copy on your machine.
  2. Create a branch for the feature or fix you are working on.
  3. Make changes to the files.
  4. Stage the changes you want to include (you choose which files to include in the next commit).
  5. Commit the staged changes with a clear message, e.g. "Add login form validation".
  6. Repeat steps 3–5 as you work.
  7. Push your branch to the remote repository.
  8. Open a pull request (on GitHub) or merge request (on GitLab) β€” a formal proposal to merge your branch into main. Team members review your code before it is accepted.
  9. After approval, merge the branch into main.

Why Version Control Matters

Undo mistakes. If a new change breaks everything, you can revert to the last working commit rather than trying to remember what you deleted.

Parallel work. Multiple developers can work on different features at the same time without getting in each other's way. Each feature lives in its own branch.

Audit trail. Every change is logged with who made it and why. When a bug appears, you can search the history to find exactly which commit introduced it β€” a process called git bisect.

Experimentation. Branches let you try risky ideas without touching the working code. If the experiment fails, simply delete the branch.

Key Words

  • Repository β€” the folder (and its history) tracked by Git
  • Commit β€” a saved snapshot of the project at a point in time
  • Branch β€” an independent line of development that diverges from the main history
  • Merge β€” combining changes from one branch into another
  • Merge conflict β€” a situation where two branches changed the same part of a file in incompatible ways
  • Push β€” uploading local commits to a remote repository
  • Pull β€” downloading commits from a remote repository to your local copy
  • Clone β€” creating a local copy of a remote repository
  • Pull request / merge request β€” a proposal to merge a branch, usually reviewed by teammates before acceptance