What’s version control?
The easiest way to understand version control is to look at how you version control your stuff. Let’s imagine you’re building a Very Important Presentation for your Managing Director. What’s your workflow?
- Make change to a slide (Move Very Important Box 1px To The Left)
- Save changes
- Make other changes
- Save those changes
What happens if you want to go back to a previous version, because you made a bad change, or your MD told you to scrap all of the stuff he just told you to do? You have a couple of pretty weak options:
- Undo (Command Z) – this only works for relatively recent stuff, you have to do it one by one, you lose everything that you’ve built since then, etc.
- Save files in versions (presentation_final_1, presentation_final_2) – takes a lot of time, unclear progress, and very inefficient
Version control exists to solve this exact problem. Instead of just saving and losing all of your previous progress, version control makes you commit your changes as new versions while still keeping the old ones: and you can go back to any commit at any point in time. It’s basically as if you saved every group of changes as a new file separately (like option #2 above), but in a much simpler, more efficient way.
Version control is really popular in software engineering, but not in business contexts: that’s because all of those problems we talked about are way worse when you’re developing an application. Modern applications can have tens of thousands of lines of code (often way more), all dependent on each other, and being worked on by multiple people. Imagine building a presentation with 10,000 slides and 30 other analysts. Actually, don’t. I care about you.
This is all a little abstract: let’s dive into Git, the most popular actual version control software, and see how it works in practice.
