The problem Git solves
Summary: before Git, developing meant living with the fear of breaking your code, losing your work, and overwriting a colleague's. This lesson describes precisely the problem — because you cannot understand the solution until you have felt the pain.
1. The scenario every developer has lived through
You have been working on a project for two weeks. On Monday, everything works. On Tuesday, you add "just one small feature". By the evening, nothing works anymore.
Then comes the only real question:
How do I get back to the version that worked on Monday?
Without version control, the answer is almost always "impossible":
| Attempt | Result |
|---|---|
Repeated Ctrl+Z | History lost since the editor restarted |
| A backup copy? | You never made one |
| Memory | Impossible to remember every line changed in 8 hours |
| System trash | Too late, it was emptied |
That is pain number 1. There are others.
2. The "dated folders" method
Faced with this problem, a beginner's first idea is natural but catastrophic: manually duplicating the project at every important step.
What this method cannot do:
- Tell you which one is the "real" latest version.
- Show what changed between
v1andv2. - Tell you why a file was modified.
- Find the exact file modified three days ago.
- Reclaim disk space when the project weighs 5 GB.
Result: chaos, duplicates, a full disk, and permanent doubt about which version to send the client.
3. The nightmare: collaborating without versioning
The problem becomes exponential as soon as a second person touches the code.
In this scenario, there is no warning at all. Whoever sent their file last overwrites the other person's work. The bug is discovered 3 weeks later, in production, when a customer reports a regression.
This is exactly what happened in companies before 2005 — the year Git was born.
4. The production bug, with no plan B
Third scenario, the most stressful one. The code is in production. A user reports a critical bug. You must answer three questions in under an hour:
Without a reliable history, these three questions have no fast answer. Every lost minute costs money, customers, credibility.
5. What Git changes, in one sentence
Git was born precisely to answer these four pains:
| Pain | Git's answer |
|---|---|
| Rolling back | Return to any version, in 1 command, in < 1 second |
| Chaos of dated copies | A single folder, a readable linear history |
| Silently overwriting a colleague's work | Automatic conflict detection, assisted merging |
| Production bug with no traceability | Every line of code knows who wrote it, when, and why |
Within a few years, 95% of professional developers adopted Git. Not by chance: because every one of them lived, at least once, one of the scenarios described above.
Remember in 30 seconds
- Without version control, you lose work, you overwrite other people's, and you cannot roll back.
- The "dated folders" method makes the problem worse instead of solving it.
- Git has been the standard answer to these four pains since 2005.
- You have not yet seen how it works. That is the subject of the next lesson.