The problem Git solves

The problem Git solves

You already know your way around a terminal from The Terminal, Linux & Bash: you can cd into folders, create files, and run commands. Now imagine working on a real project for weeks.

Version control is software that records every version of your files, so you can see what changed, when, why, and by whom, and jump back to any earlier version.

Without it, projects die in familiar ways:

• You improve a file, break it, and cannot remember what the working version looked like.
• Your folder fills with report_final.txt, report_final_v2.txt, and report_final_REAL.txt.
• Two people edit the same file and one person's work silently disappears.

Before learning the tool, let's feel the pain it removes. We'll do backups the manual way.

Versioning by hand

This session manages versions the only way available without a tool: every time the recipe changes, the whole file is copied under a new name. Watch the clutter begin.

mkdir project
cd project
echo "Chocolate chip cookies" > recipe.txt
cp recipe.txt backup1.txt
echo "Use brown butter" >> recipe.txt
cp recipe.txt backup2_final.txt
ls
cat recipe.txt

Output

backup1.txt
backup2_final.txt
recipe.txt
Chocolate chip cookies
Use brown butter

Every command here is one you already used in the terminal course, and that is the point: manual versioning needs no new tools, which is exactly why people fall into it. The > operator created recipe.txt with a single line, and >> appended the second line rather than replacing the file.

Two edits have produced three files. backup1.txt holds the one-line version, backup2_final.txt holds the two-line version, and recipe.txt is the live copy that will keep changing.

Why manual copies fail

After two edits we already have three files. After a month we would have fifty, and the copies answer none of the important questions:

• What changed between backup1.txt and backup2_final.txt? You would have to compare them by eye.
• Why was the change made? No copy carries an explanation.
• Which copy is safe to delete? Nobody remembers.

A version control tool fixes all three. It stores each version once, attaches a message, an author, and a date to it, and can print the exact lines that changed between any two versions on demand.

Reproducing the pattern in a journal

The same manual approach applied to a daily log. A file is created, copied as a snapshot, and then extended, so the copy preserves the earlier state.

mkdir journal
cd journal
echo "Day 1: started learning Git" > log.txt
cp log.txt day1_copy.txt
echo "Day 2: made my first backup" >> log.txt
ls
cat log.txt

Output

day1_copy.txt
log.txt
Day 1: started learning Git
Day 2: made my first backup

The two redirection operators do different jobs, and the order matters. echo "text" > file creates or overwrites, while echo "text" >> file appends, so using > for the Day 2 line would have destroyed the Day 1 line instead of adding to it.

The cp runs before the append, which is what makes day1_copy.txt a genuine snapshot of the earlier state. Copying afterwards would have captured both lines and preserved nothing.

A month into a project with fifty copies like report_v2_final.txt, the copies can answer none of the important questions on their own.

A copied file stores only its contents. Nothing records why the change was made, who made it, or when, because a filename is the only place that information could live and a filename is not built to carry it. Finding what changed between two copies means opening both and comparing them by eye, which is slow and unreliable on anything longer than a page.

Version control attaches a message, an author, and a timestamp to every saved version, and it can print the exact changed lines between any two of them on demand. That is the whole difference: the copies preserve states, while a version control tool preserves changes along with their explanations.

Git and GitHub are two different things

Git is the version control tool that won. It was created in 2005 by Linus Torvalds (the creator of Linux, which you met in the terminal course). It is free, it runs entirely on your own computer, and nearly every software company uses it.

GitHub is a website that stores copies of Git projects online so people can share them. Git is the tool, GitHub is a hosting service built around the tool. You can use Git your whole life without ever touching GitHub, and there are competitors to GitHub (GitLab, Bitbucket) that also host Git projects.

We spend the first six units purely on Git, on your machine. GitHub arrives in unit 7.

The sentence is backwards. GitHub is a website that hosts projects tracked by Git, so using GitHub means using Git.

Git is the version control program running on your own computer, and it is what actually records versions. GitHub is one of several sites that store Git repositories online, alongside GitLab and Bitbucket. The dependency runs one way: GitHub needs Git, and Git does not need GitHub.

The confusion is understandable, since most people meet the website first and the tool second. A useful way to keep them apart is that everything in the next six units happens with no internet connection at all.