The Backup Problem

Imagine that you have some big project. You write it, at some point you reach some logical completion and roll out version 1.0, which users start using.

The work doesn't end there, however, and you roll out version 1.1 with bug fixes and additions, then version 1.2, then 1.3, and then you rewrite everything again and announce the release of version 2.0. And so on - the work on the project usually never ends.

During the development process, however, there is a risk of breaking something in the code, or accidentally deleting the project or part of it. In order not to lose all the work, you periodically save the project code in a separate folder. You simply number your saves in order, indicating some commentary on the save, about what changes you made or what functionality you have already done by this moment of saving.

However, it suddenly turns out that you can't just roll out version 2.0, because users of the first version are upset - they are not yet ready to switch to the second. Okay, you say, and start working on the second version, simultaneously releasing updates to the first. Your project splits into two folders - one for the first version and one for the second. The backup folder also splits. At the same time, some of the code in the first and second versions is the same. When making edits to this code in one version of the project, you must remember to make edits in the other version as well. However, you sometimes forget to do this. Strange bugs appear. The work is at a standstill.

While working on version 2.0, you decided to add a new feature. However, it takes too long to do, so you decide to split the second version into two folders, duplicating the code. In the first folder, you will continue developing your project, and in the second, you will make the feature you came up with. Finally, the feature is finished. During this time, the main project has already become version 2.3. Now you need to merge the code with the feature with the main project code. You start copying files with the code to the main folder, simultaneously resolving conflicts between the new code and the old. This takes you three working days. The work is at a standstill.

The project has grown. You decide to ask a friend for help. You give your friend a task and send him an archive with the project. Your friend does the task and returns the archive with the new files, as well as the old ones that he has changed. You spend half a day separating the new files from the old ones. Then you spend another day integrating the changes into your files.

You call two more friends for help. Now there are four of you. Every day you are sent archives with the work done. You integrate new parts into the project and send everyone archives of the project with changes. The work progresses slowly, because while you are integrating one change, your friends are waiting for you to send them a new version of the project and cannot work further, so as not to get completely out of sync.

The backup folder already contains gigabytes of code. Mostly, it contains duplicates, because by changing a small part of the code, you still reset the entire project. You decide to clean this folder by deleting the first hundred versions. A week later, it turns out that the deleted versions contained the code for a separate feature, which you then abandoned, and now decided to return. But the code with this feature has already been deleted, and it is nowhere to be found. You write this feature again. The work is at a standstill.

Doesn't sound like much, does it? However, developers actually used to work the way I described above. Of course, it was very inconvenient. That's why a special Git system appeared, the capabilities of which we will talk about in the next lesson.