I\u2019ll use an analogy to introduce version control. See the Wikipedia entry on revision control for a saner explanation.<\/p>\n
I\u2019ve played computer games almost all my life. In contrast, I only started using version control<\/a> systems as an adult. I suspect I\u2019m not alone, and comparing the two may make these concepts easier to explain and understand. Think of editing your code, or document, as playing a game. Once you\u2019ve made a lot of progress, you\u2019d like to save. To do so, you click on the\u00a0Save\u00a0<\/i>button in your trusty editor<\/a>. But this will overwrite the old version. It\u2019s like those old school games which only had one save slot: sure you could save, but you could never go back to an older state. Which was a shame, because your previous save might have been right at an exceptionally fun part of the game that you\u2019d like to revisit one day. Or worse still, your current save is in an unwinnable state, and you have to start again.<\/p>\n When editing, you can\u00a0Save As\u2026\u00a0<\/i>a different file, or copy the file somewhere first before saving if you want to savour old versions. You can compress<\/a> them too to save space. This is a primitive and labour-intensive form of version control. Computer games improved on this long ago, many of them providing multiple automatically timestamped save slots. Let\u2019s make the problem slightly tougher. Say you have a bunch of files that go together, such as source code for a project, or files for a website. Now if you want to keep an old version you have to archive a whole directory. Keeping many versions around by hand is inconvenient, and quickly becomes expensive. With some computer games, a saved game really does consist of a directory full of files. These games hide this detail from the player and present a convenient interface to manage different versions of this directory. Version control systems are no different. They all have nice interfaces to manage a directory of stuff. You can save the state of the directory every so often, and you can load any one of the saved states later on. Unlike most computer games, they\u2019re usually smart about conserving space. Typically, only a few files change from version to version, and not by much. Storing the differences instead of entire new copies saves room.<\/p>\n Now imagine a very difficult computer game. So difficult to finish that many experienced gamers all over the world decide to team up and share their saved games to try to beat it. Speedruns are real-life examples: players specializing in different levels of the same game collaborate to produce amazing results. How would you set up a system so they can get at each other\u2019s saves easily? And upload new ones? In the old days, every project used centralized version control. A server some- where held all the saved games. Nobody else did. Every player kept at most a few saved games on their machine. When a player wanted to make progress, they\u2019d download the latest save from the main server, play a while, save and upload back to the server for everyone else to use. What if a player wanted to get an older saved game for some reason? Maybe the current saved game is in an unwinnable state because somebody forgot to pick up an object back in level three, and they want to find the latest saved game where the game can still be completed. Or maybe they want to compare two older saved games to see how much work a particular player did. There could be many reasons to want to see an older revision, but the outcome is the same. They have to ask the central server for that old saved game. The more saved games they want, the more they need to communicate. The new generation of version control systems, of which Git is a member, are known as distributed systems<\/a>, and can be thought of as a generalization of centralized systems. When players download from the main server they get every saved game, not just the latest one. It\u2019s as if they\u2019re mirroring the central server<\/a>. This initial cloning operation can be expensive, especially if there\u2019s a long history, but it pays off in the long run. One immediate benefit is that when an old save is desired for any reason, communication with the central server is unnecessary.<\/p>\n","protected":false},"excerpt":{"rendered":"Version Control<\/h2>\n
Distributed Control<\/h2>\n