Why Version Control Exists
By the end of this lesson
Explain the problems version control solves and what a commit actually records.
Before version control, keeping a history meant copying folders. project, project-backup, project-backup-working, project-final, project-final-v2. Everyone who has worked without it has produced that directory listing.
It fails in predictable ways: you cannot tell what differs between two copies, you cannot tell why a change was made, and if two people edit the same file, one set of work is lost.
What Git gives you instead:
- A history you can read
- Every change is recorded with who made it, when, and a message explaining why. You can see exactly what differed between any two points.
- The ability to go back
- Any previous state can be recovered. This is what makes experimenting safe — the cost of a bad idea drops to nearly zero.
- Parallel work
- Branches let several people work on different things simultaneously without overwriting each other.
- A place for review
- Changes can be proposed and discussed before they join the main line of work.
What a commit actually is
A commit is a snapshot of your project at a moment, plus a message and a pointer to the commit that came before it.
That last part is the key to understanding Git. Commits form a chain, each linked to its parent. History is not a list stored somewhere separately — it is the chain itself.
Once you see it this way, branches stop being mysterious. A branch is nothing more than a movable pointer to a commit. Creating one costs nothing — it is a new pointer, not a copy of your files. This is why Git users branch freely where older tools made it an event.
# What has changed?
git status
# Stage the changes you want to record
git add src/Employee.cs
# Record them with a message explaining why
git commit -m "Validate salary is positive before saving"
# Send them to the shared repository
git push- Staging is a deliberate step: you choose what goes into this commit rather than committing everything you happen to have touched.
- That separation is what lets you make one focused commit even when your working folder contains several unrelated edits.
Summary
- Version control replaces folder copies with a readable, recoverable history
- A commit is a snapshot plus a message plus a link to its parent
- A branch is a movable pointer, which is why branching is cheap
- Commit messages should record why, since the code already shows what
Practice
Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.
Think about it
Think about it
Why is one commit per logical change more useful than one large commit at the end of a day's work?
Show solution
Small commits can be understood, reviewed and reverted individually. If one of five changes caused a bug, you can undo exactly that one.
With a single large commit, reverting the bug means reverting four unrelated pieces of good work along with it, and reviewing it means reading everything at once.
Knowledge check
Nothing is recorded and there is no score. The explanation appears either way.
Saved in this browser only.