If you don't use version control, a common workflow is to create different subdirectories to hold different versions of your project in different states, for example
final. Of course, then you always end up with
final-updated-revised as well. The problem with this is that it becomes difficult to work out if you have the right version of each file in the right subdirectory, and you risk losing work.
One of the reasons Git is popular is its support for creating branches, which allows you to have multiple versions of your work, and lets you track each version systematically.
Each branch is like a parallel universe: changes you make in one branch do not affect other branches (until you merge them back together).
Note: Chapter 2 described the three-part data structure Git uses to record a repository's history: blobs for files, trees for the saved states of the repositories, and commits to record the changes. Branches are the reason Git needs both trees and commits: a commit will have two parents when branches are being merged.
In the diagram below, each box is a commit and the arrows point to the next ("child") commit. How many merges have taken place?