Version Control Before Git

Before learning Git itself, it helps to understand the problem it was built to solve. This lesson looks at how developers managed changing projects before Git, why that approach broke down, and how backups, manual versioning, and version control systems differ from one another.

1. Managing project versions manually

Before version control existed, it was common to manage a changing project by keeping several folders side by side:

project/
project-v1/
project-v2/
project-final/
project-final-fixed/
project-final-fixed-really-final/

Each folder is a full copy of the project at some point in time. Whenever a developer wanted to try something risky, or simply wanted a safety net before a big change, the easiest option was to duplicate the whole project folder and keep working in the copy.

This works for a while on a small, single-person project. As the project grows, or as more than one person touches it, this approach quickly becomes unmanageable — which is exactly why developers needed a better way to track changes.

2. Problems with manual copies

Keeping versions as separate folders creates real, practical problems:

Wasted storage, since every copy duplicates the entire project.
Confusing folder names that stop meaning anything after a few rounds.
Difficulty identifying which copy is actually the correct or current one.
Difficulty comparing what changed between two folders.
No reliable change history — only whole snapshots, not a timeline.
No clear record of who changed something.
No explanation of why a change was made.
Difficulty knowing when a change happened.
Difficulty restoring just one part of the project instead of the whole folder.
Accidental overwriting of another developer’s work.
Extremely difficult collaboration and manual merging.

A simple scenario makes this concrete: two developers are working on the same project. One of them copies the project folder onto a flash drive, makes changes at home, and brings it back the next day. Meanwhile, the other developer changed the same file at the office. Whoever copies their folder back last usually overwrites the other person’s work — often without either developer realizing anything was lost.

3. Backup

A backup is a copy of data created mainly for recovery — so that work can be restored after loss, corruption, accidental deletion, or a system failure.

A few points are worth clarifying:

A backup is not necessarily manual — it does not have to mean someone copying a folder by hand.
A backup is not necessarily a complete copy every time; many backup systems only store what changed.
Backups may be automatic, incremental, or scheduled, running in the background without a developer thinking about them.

Even a well-designed backup system does not provide a proper software-development history. It usually cannot tell you what changed inside a file, who made a particular change, or why that change was made — it only restores data to a point in time.

4. Manual versioning

Manual versioning means deliberately keeping multiple named states of a project, often as folders or archive files such as:

project-v1.zip
project-v2.zip
project-final.zip

This does preserve several states of the project that a developer can go back to. However, everything about managing those states is still manual:

Naming.
Dates.
Comparing one version with another.
Storage.
Restoring a version.
Collaboration.
Merging changes from different people.

Manual versioning is a step up from having no plan at all, but it is not the same thing as a real version control system — nothing here tracks history, authorship, or reasons for a change automatically.

5. Version control system

A Version Control System (VCS) is a system that records and manages changes to files over time.

A VCS helps developers:

Track the project’s history.
Compare versions.
Identify who changed something.
Know when a change happened.
Record why a change was made, through commit messages.
Restore previous states.
Create separate development lines to work on different things at once.
Combine work from multiple developers.
Detect conflicting edits.

6. Centralized version control systems

In a centralized model, with SVN as a common example, the main repository and its complete history live on one central server.

Developers retrieve files from that central server.
Commits are normally sent directly to the central repository.
Many repository operations — browsing history, comparing versions, committing — depend on having access to that server.
If the connection or the server becomes unavailable, normal collaboration through the repository is interrupted.
Developers may still be able to edit their local working files, but they cannot interact normally with the central repository while it is unreachable.

If the central server fails and there is no reliable backup of it, the project’s shared history can be lost entirely — this is one of the main risks of relying on a single central copy of the history.

7. Distributed version control systems

Git is a Distributed Version Control System (DVCS). In a distributed system, every clone of the repository normally contains:

The project files.
A full local repository.
The commit history available at the time of the clone or the last fetch.
Branch and reference information.

Because each clone already has the project’s history, developers can continue working locally without an internet connection. Common operations that work entirely offline include:

git add
git commit
git log
git diff
git branch
git merge
git rebase

Operations that involve a remote repository still require access to that remote, since they need to exchange data with it:

git fetch
git pull
git push

8. Git can still use a central shared remote

A common misconception is that “distributed” means there is no shared central server at all. That is not accurate.

Using a shared server is a team workflow decision, made on top of Git — not a requirement of how Git itself works. Even when a team agrees on one shared remote, every developer still has a complete local Git repository of their own.

9. Repository versus remote

At this point it is enough to know the basic distinction between two terms that will come up often:

Local repository: the Git repository stored on the developer’s own machine.
Remote repository: another repository reachable over a network, such as one hosted on GitHub.

The commands used to work with remotes in detail are covered in later lessons — for now, it is enough to recognize the difference between “my repository” and “a repository somewhere else.”

10. Comparison table

Feature	Backup	Manual versioning	Centralized VCS	Distributed VCS
Main purpose	Recovery	Keep manual versions	Manage history centrally	Manage complete local and shared history
Detailed change history	Usually no	Very limited	Yes	Yes
Author tracking	Usually no	Usually no	Yes	Yes
Offline commits	Not applicable	Manual copying	Usually no	Yes
Collaboration support	No	Poor	Yes	Yes
Local repository history	No	Folder copies only	Limited working copy model	Full local repository

11. Practical scenario

Two developers, working independently, both edit the same file.

If they simply exchange files with copy/paste, whoever pastes last can silently overwrite the other person’s changes.
Replacing the entire file with someone else’s version may delete valid work that was never meant to be discarded.
A version control system instead records both sets of changes as distinct, attributed edits.
When the two sets of changes touch different, unrelated parts of the file, the system can usually combine them automatically.
When both developers changed the same lines in incompatible ways, the system reports a conflict instead of silently guessing — leaving the decision to the developers.

The mechanics of resolving a merge are covered in a later lesson; the important idea here is that a version control system makes conflicting edits visible instead of letting one silently erase the other.

12. Summary

Backup protects data.
Manual versioning keeps manually named copies.
A Version Control System manages the history of changes.
A centralized VCS keeps the authoritative repository on one central server.
A distributed VCS gives every developer a local repository with history.
Git is a Distributed Version Control System.

13. Knowledge check

1. What is the difference between a backup and a version control system?

A backup exists mainly for recovery — restoring data after loss, corruption, or deletion. It does not normally track individual changes, authors, or reasons for a change. A version control system is built specifically to manage the history of changes: who changed what, when, and why, with the ability to compare and restore specific versions.

2. Why is Git distributed even when a team uses GitHub as its main server?

Using a shared remote such as GitHub is a team workflow choice layered on top of Git, not a change to how Git itself works. Every developer who clones the repository still gets a complete local repository with its own history, so Git remains distributed regardless of whether the team also agrees on one shared central server.

3. Which Git operations can be performed locally without internet access?

Operations that only involve the local repository — such as git add, git commit, git log, git diff, git branch, git merge, and git rebase — work without internet access. Operations that must exchange data with a remote repository, such as git fetch, git pull, and git push, require access to that remote.

4. Why is copy/paste dangerous when two developers modify the same file?

Copy/paste has no concept of history or authorship — it simply replaces content. If two developers changed the same file independently, whoever pastes their version last can silently overwrite the other person’s changes, with no record that anything was lost and no chance to combine both sets of work.