PublishedBEG-046-L01

Why version control

Lesson 1 of 8
12 min read
Beginner

On This Lesson 11 topics

Lesson Overview
Learning Objectives
Written Explanation
Examples
Backend Insight
Common Mistakes
Exercises
Mini Challenge
Summary & Next Lesson
References
Practice

Lesson Overview

Sooner or later every programmer ends up with a folder that looks like this: Bank, Bank-final, Bank-final2, Bank-final-REAL, Bank-final-REAL-fixed. Nobody can say which copy is the good one, what changed between them, or why. This lesson explains the problem behind that folder and the tool that solves it: version control.

You will learn what a version control system records, why it is more than "backup", how Git (the tool this module teaches) works at a high level, and how to check that Git is installed on your machine. You will not make a commit yet. That is the next lesson. The goal here is to understand why the commands you are about to learn exist, so they feel like answers to real problems instead of a list to memorise.

You already know how to use a terminal (BEG-006) and you have written Java programs. That is all you need. The module ends with you putting your Bank Accounts project under Git, creating a deliberate conflict, and resolving it. The analogy used throughout: a photo album of your project, where every page is a snapshot you can flip back to.

Learning Objectives

By the end of this lesson you will be able to:

Describe the problems of managing versions by copying folders.
Define a version control system (VCS) and name what it records for every change: who, when, and why.
Explain how a VCS lets you return to an earlier state of a project.
Explain how a VCS lets several people work on the same code without overwriting each other.
Describe in plain words what Git is and why it keeps the whole history on your own computer.
Tell Git apart from GitHub.
Check from the terminal whether Git is installed, and read its version.

Written Explanation

The problem: copies and "final2"

Imagine you have a working Java program and you want to try a risky change. The safe-feeling habit is to copy the folder first. Do that a few times and you get problems that copying cannot solve:

No story. Which copy is newest? Looking at folder names or file dates tells you very little.
No reason. You can see that Account.java differs between two copies, but not what changed or why.
No safe merging. If you and a teammate each edited a copy, combining the two means comparing files by eye and pasting between them. One slip and someone's work is lost.
Wasted space and confusion. Every copy repeats the whole project.

These are not signs of a careless programmer. They are what happens when you use the wrong tool.

What a version control system does

A version control system records the changes made to a set of files over time, so that you can look at, compare, and restore earlier states. For every recorded change it keeps three kinds of information that copies cannot give you:

Question	What the system keeps
Who changed it?	The author's name and email
When?	The date and time
Why?	A short message the author writes

Each recorded state is called a snapshot in this module (Git calls it a commit; the next lesson makes one). Think of the project as a photo album. A snapshot is one photo of the whole project at one moment. You can flip back to any page, look at it, compare two pages, or start a new line of pages from an old one. Nothing you recorded is lost just because you kept working.

This gives you four things:

History. A list of snapshots, each with who, when, and why.
Undo at project level. If a change breaks the program, you can go back to a state that worked.
Comparison. You can see exactly which lines changed between two snapshots.
Parallel work. Different people (or you on different ideas) can work on separate lines of snapshots and combine them later. Later lessons call these lines branches and the combining step a merge.

Version control is not the same as backup

A backup is a copy kept somewhere safe in case you lose the original. Version control keeps many states of the project and explains how they relate to each other. A backup answers "can I get my files back?". Version control also answers "what changed last Tuesday, and who did it?". History stored only on one laptop is still lost with the laptop, so keep copies elsewhere too.

Git: a distributed system that lives on your computer

Several version control tools exist. Git is the one almost every Java team uses, so it is the one this module teaches. It was designed to be distributed, which in practice means two things for you:

Every copy of a project contains its full history. You do not need a network connection to look at the history, compare versions, or record new snapshots. According to the Pro Git book, nearly all Git operations only need local files and resources.
Git thinks in snapshots, not in lists of file differences. At each commit it records what all files look like at that moment, and for a file that did not change it just refers to the copy it already has. That is why the album analogy fits.

Git also has a simple rule about where your work can be. A file is modified (changed but not recorded), staged (marked to go into the next snapshot), or committed (safely stored in the history). The next lesson walks through all three with real commands.

Git is not GitHub

Beginners often use the two names as if they were one thing. They are not:

	Git	GitHub
What it is	A program that runs on your computer	A website and service that hosts Git repositories
Needs internet	No, for everyday work	Yes
Where it is taught	This module	BEG-047

You can use Git for years without ever touching GitHub. The module after this one (BEG-047) is about connecting your local history to a hosted copy.

Checking that Git is installed

Open a terminal (the Windows Terminal, PowerShell, Git Bash, or a Linux or macOS shell; the exact name depends on your system). Type:

bash

git --version

You should see a line like git version 2.44.0.windows.1. Your number will be different, and that is fine. If the terminal says the command is not found, Git is not installed or not on your PATH. Install it from the official download page at git-scm.com for your operating system, then open a new terminal and try again. Git also wants to know who you are, because every snapshot carries an author. You set that once per computer:

bash

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Use your own name and an email address you are happy to have stored in your project history. We return to this at the start of the next lesson.

Examples

Example 1: The folder of copies (simple)

Here is the folder of a student working alone for one week:

text

bank/
bank-final/
bank-final2/
bank-final-REAL/
bank-final-REAL-fixed/

On Friday the program has a bug that was not there on Monday. To find it, the student opens two folders and compares files by eye. The folder names say nothing about what each copy contains.

With version control the same week looks like this (the real command arrives in lesson L03; you only need to read the shape here):

text

a1b2c3d Fix negative balance after withdraw
9e8f7a6 Add deposit and withdraw methods
5d4c3b2 Add Account class with balance

Three snapshots, newest on top, each with a message that says what happened. The Friday bug can be located by asking which snapshot first contained it. The two lists describe the same work; only one of them can be searched, compared, and trusted.

Example 2: A risky experiment (practical)

You want to change how interest is calculated in the Bank Accounts project, but you are not sure it will work.

Copy approach: copy the folder, edit the copy, and if it works, carry the changes back into the original by hand.
Version control approach: record a snapshot of the working project first. Make your changes. If they break the program, return to the snapshot. If they work, record a new snapshot such as "Calculate interest monthly".

The real difference is confidence: when going back is cheap and certain, you try things you would otherwise avoid.

Example 3: Two people, one file (realistic)

Aisha and Omar both work on Account.java. Aisha adds a withdraw method at the bottom. Omar renames a field at the top. Both start from the same version.

Copy approach: they send each other files by chat. Whoever saves last wins, and the other's change disappears without any warning.
Version control approach: each records their own snapshot. When their work is combined, Git sees that they edited different parts of the file and joins the changes automatically. If they had changed the same line differently, Git would stop and ask a human to decide. That situation is called a merge conflict. It is normal, and lesson L05 teaches you to resolve one by hand.

This is the main reason professional teams cannot work without version control: it is what makes it safe for many people to change one codebase every day.

Backend Insight

Backend code is rarely written once and left alone. A service goes live, users depend on it, and then it keeps changing: a new rule, a fix, a faster query. Version control is the record of how the running system got to its current state.

When something breaks in production, the first questions are usually: what changed recently, who changed it, and why? A history of small snapshots with clear messages answers those in minutes. A folder of copies cannot.

Version control is also how code reaches servers. Build and deployment tools in later modules start from a specific snapshot of the code, so a team can say exactly which version is running. In the roadmap's teamwork module (JNR-053) you will build on this module with the branching and review workflows teams use every day.

Common Mistakes

Mistake 1: "Git is just a backup tool"

Incorrect: "I will use Git so I do not lose my files."
Correct: "I will use Git to record the history of my project, and I will also keep copies elsewhere in case my computer fails."

Why it happens: the first benefit people notice is being able to get old files back. How to avoid it: remember the three questions (who, when, why) and the ability to compare and combine. A backup gives you none of those.

Mistake 2: Mixing up Git and GitHub

Incorrect: "I cannot use Git because I have no GitHub account."
Correct: "Git works on my own computer. GitHub is an optional place to host a copy."

Mistake 3: Thinking version control is only for teams

A solo project benefits from the same history, undo, and experiments. Starting alone costs a few minutes and is a good habit.

Exercises

Try each exercise before opening the solutions.

Level A: Foundation

A1. In one sentence, define "version control system".

Show solution A1

A1. A version control system records changes to files over time so that you can see earlier states, compare them, and restore them.

A2. Name the three pieces of information a VCS keeps for each change, and give a one-line example of each for a change to a Java file.

Show solution A2

A2. Who: the author, for example "Sara Student". When: the date and time, for example "4 November, 14:05". Why: a message, for example "Fix negative balance after withdraw".

A3. True or false, with a reason: "Git needs an internet connection to record a snapshot."

Show solution A3

A3. False. Git stores the full history on your own computer, so recording snapshots and viewing history work offline. A network is needed only when you exchange history with another computer, which is covered later (BEG-047).

Level B: Application

B1. A teammate says: "We do not need Git, we upload project-v1.zip, project-v2.zip, and so on to a shared drive." List three problems with this approach that Git solves.

Show solution B1

B1. Any three of: no record of who made each change or why; hard to compare versions line by line; two people editing different zips must merge by hand and can overwrite each other; the zips repeat the whole project every time; it is easy to start from the wrong version; there is no safe way to try something and discard it.

B2. Explain the difference between Git and GitHub in two or three sentences, as if to a friend who has never programmed.

Show solution B2

B2. Git is a program on your computer that records the history of a project. GitHub is a website that can store a copy of that history online so that others can see it and share work. You can use Git without GitHub.

B3. Open a terminal and run the command that shows the Git version. Write the command and what you saw. If Git is missing, write what you would do next.

Show solution B3

B3. The command is git --version. Example output: git version 2.44.0.windows.1 (yours will differ). If the command is not found, install Git from git-scm.com, open a new terminal, and run the command again.

Level C: Challenge

C1. Two students each take a copy of a Java project on Monday. On Wednesday both have changed Main.java. Describe what could go wrong when they combine their work using copies, and how a version control system helps. Mention the word "conflict" and say whether it always means something went wrong.

Show solution C1

C1. With copies, whoever overwrites the other's file wins, or they must compare the two Main.java files by eye, which is slow and error-prone. With a VCS, each records their changes as snapshots; when combined, Git joins edits made to different parts of the file automatically. If both changed the same lines, Git reports a conflict and asks a human to decide. A conflict does not mean something went wrong; it means a decision that only people can make.

C2. A program printed the correct total last week and prints a wrong one today. Describe step by step how a history of snapshots helps you find the cause, compared with having only the current files.

Show solution C2

C2. With history you can look at an older snapshot that worked, compare it with the current one to see which lines changed, and narrow the search by trying snapshots in between. The messages tell you why each change was made. With only the current files you can only read the code and guess what used to be there.

Mini Challenge

Pick a project you worked on that has several files (it can be a Java exercise from an earlier module). Write one page, in your own words:

Three moments in that project where a history of snapshots would have helped you (for example, a change that broke something).
For each moment, the message you wish you had written for the snapshot before it.
One sentence that explains why this history would be more useful than a folder called project-final2.

Check your work: each moment mentions who, when, or why; your messages say what changed rather than just "update"; and your last sentence mentions comparing or going back.

Summary & Next Lesson

Key takeaways

Copying folders gives no story, no reasons, and no safe way to combine work.
A version control system keeps snapshots of the whole project with who, when, and why.
It lets you go back, compare, and work in parallel with other people.
Git is a distributed system: every copy holds the full history, and most work is local.
Git runs on your computer; GitHub is a separate service that hosts Git repositories.
git --version checks that Git is installed.

Next lesson

The next lesson, "Repositories, staging, and commits", turns the album idea into commands: you will create a repository, stage a change, and record your first snapshot with a clear message.

Self-check

Name one thing version control gives you that copying folders does not.
What three pieces of information does a VCS keep for each change?
Does Git need the internet to record a snapshot?
Is GitHub the same thing as Git?
Which command tells you whether Git is installed?

Show answers

Any of: who and why for each change, safe merging with teammates, or easy return to an old version.
Who made the change, when, and why (the message).
No. The full history is on your own computer, so most operations are local.
No. Git is the program that records history; GitHub is a website that hosts Git repositories.
git --version.

References

Pro Git book, "What is Git?". It supports the points that Git stores snapshots rather than file differences, that nearly all operations are local, and that files move between modified, staged, and committed states.
Git documentation, git init. It describes a repository as a .git directory created inside the project, which is why the history lives on your own computer.
I did not fetch a source for the name of Git's installer pages or for how widely Git is used; "almost every Java team" is a general observation, not a measured figure.

Practice

Apply this lesson with the module's lab, exercises and quiz.

Lab and exercises Quiz

Marking a lesson complete is optional and you can undo it any time. Your progress stays in this browser.

Continue to next lesson