Version Control – Why, When, and When Not (Part I)
10 minutesModule: Version Control – Why, When, and When Not (illustrated with Git)
Prefer reading? The full written version is below
Note: This is the written companion to the video above. Same content, optimized for reading – so you can watch, read, or both, depending on how you learn best.
Is everyone around you using words like version control or Git, and you’re still not sure why you need it and whether you should use version control? Then this might be just the thing for you. In this lesson, we’ll have a look at why version control is worth its salt, when it helps, and when not – explained using Git.
Let’s start with the why. Version control is a system that lets you record how one or more files change over time, to give you control over these file changes or over the different versions of your files.
Control can mean a few different things. When you’re starting out, what may help most is being able to restore earlier versions of your files or simply reuse parts of them. This is especially useful when something suddenly stops working after a change.
Maybe you’ve been using version control in one form or another already. Before version control systems caught on, a primitive way of version control was simply copying files into a separate folder, for instance a folder with a date in its name. If you’ve done this at some point, you may have run into a number of issues, from losing track of where you were, to accidentally changing or deleting the wrong file, to discovering that something in your code broke with no idea as to when or why. Add a collaborator or two working with copies of the same files on their machines, and you can imagine how things can get complicated really fast.
These are exactly the kinds of issues version control systems were created to address. Instead of you juggling copies in different folders, a version control system does the tracking for you, so you always know where you are, what changed or got removed, and how to get back to a working state if necessary.
Let’s understand a bit better what version control is by looking at possibly the most popular version control system currently, which is Git.
Git
As mentioned earlier, version control lets you record how one or more files change over time. Because of the word change, you might be tempted to think this means recording the files, along with the changes made to each file over time. And this really is how many version control systems work – as a fun fact, storing just the file changes is called delta-based version control.
Spoiler alert: This is not how Git works. Instead of storing file changes, Git stores the entire state of your project at a specific moment in time. This is also called a snapshot, because Git takes a snapshot of what all your files look like at that moment and stores a reference to that snapshot.
It may initially sound less storage-efficient than storing changes, but Git handles this efficiently. For instance, if a file hasn’t changed, Git will not store it again, but will only store a link to the previous version of the file; moreover, Git compresses stored data automatically over time. And storing snapshots also makes operations fast, because Git only needs to look at local snapshots instead of reconstructing the history of changes from scratch.
Storing a snapshot
To store a snapshot of the current state of your project using Git, you need to do what is called a commit. Committing something means that this something is safely stored in your project’s history on your machine. You also need to tell Git what this is: What should be included in this commit from the files you have changed since your last commit.
You decide what to include, and Git stores that snapshot safely on your computer. But all these snapshots live only on your computer. If your machine breaks or is gone for whatever reason, so are all your snapshots.
Remote repositories
This means you need a safe place elsewhere, on the internet or a network, where Git can store copies of these snapshots safely. This safe place is called a remote repository.
To send your snapshots to your remote repository, you need to do a push. Later on, when you’ll be working on other projects or with other people, you’ll also want to pull – to get snapshots from the remote repository back to your machine. For collaboration, pulling and pushing is the way everybody gets to keep their work in sync: pulling gets their changes to you, while pushing sends your changes to them.
That’s pretty much the gist of version control and Git, we’ll cover the technical details later on. In the second part of this module, we’ll have a look at when you should be using Git and when you’re better off using something else.