Version control — Computing, 11–13
How a project keeps a history of changes so you can understand or undo them. Computing, 11–13 years.
Idea
Version control records meaningful changes to a project over time. Instead of keeping files named “final”, “final2” and “really-final”, you save a labelled checkpoint and can see what changed. Several people can work on copies and later combine their work in an organised way.
Why
Projects change, and a new change can accidentally break something that worked yesterday. Without a history, finding the cause means comparing guesses or losing later work. Version control was created to let teams record decisions, compare stages and return safely to an earlier working state.
Worked example
You build a quiz and save version 1: it has five questions. You add a score screen and save version 2. Then a change makes every answer look correct, so you compare versions 1 and 2 and find the changed line. You fix that line, save version 3, and keep the useful score screen without throwing away the whole project.
Common trap
A reasonable mistake is saving every tiny action as a separate official version. That creates a noisy history in which useful milestones are hard to find. A checkpoint should describe a meaningful working change, such as “add timer” or “fix score calculation”, while unfinished experiments can stay separate.
Where it appears
Version control is used for game code, websites, apps, robot projects and even documents with many contributors. A team can review a proposed change before adding it, while an individual can experiment without fearing permanent damage. Public code projects use the history to explain how their software grew.
Keep exploring
Other languages
Loading MyLeoNes™…