There was a time in my career when I did not use any form of version control. Well, actually, I did. I basically copied the folder I was working on and appended a date to it. I survived and chances are that if you do the same so will you. However, when I finally made the move to Git (the version control system of choice) it made my life a lot better and made updating code a lot easier.
Here are a few reasons why you should keep your code under version control:
DISTRIBUTED BACKUP
Keeping a copy of your code is always a good idea. Keeping a copy of the code you’re currently busy with is even better. A distributed version control system like Git allows you to store your main code and your work in progress on a server or service (like Gitlab or Github). This means that a stolen or corrupted device doesn’t lead to a loss of code.
To add to that, because Git is distributed, it means that every person in your team that has cloned the project also has a copy of the code. There would have to be a catastrophic failure for a complete loss of code.
MERGING CHANGES TO CODE
I’m slightly ashamed to admit this, but the first project I ever worked on didn’t have version control (you already know this) but when it came time to release code to our production servers, I would reference a list of all the files I made (on a sticky note most likely) and then upload those files to our servers. I would also hope that someone else hadn’t updated the file I was going to write over without me knowing.
Nightmare. It was also the cause of many issues and bugs, especially on production servers.
Git, and really any version control system, handles the above scenario very well. Whether you use a branching strategy or not, when you take code and either merge into another branch or try to push to a remote branch, it will first do a comparison. This can lead to a couple of scenarios:
- your code creates not conflicts and will be merged/pushed into the target,
- your code doesn’t have the latest updates and you’ll need to fetch them first, which happens with no issue and you can then push/merge your changes,
- or your code doesn’t have the latest updates and the updates you are pulling contains changes to code you also changed (known as merge conflicts). This can then be changed and your code can be merged/pushed.
For me, working in a team of people, being able to resolve these kinds of conflicts is probably the greatest feature of any version control system.
EASIER COLLABORATION
This may seem like a complete about-turn on what I was saying about Git being a distributed version control system, but using a central system like Gitlab or Github vastly improves and simplifies the process of onboarding new developers. This makes collaboration easier and opens up great policies like merge/pull requests with peer reviews.
I don’t even remember how I first shared code with colleagues but I’m guessing it wasn’t as easy as asking them to clone a project from Gitlab.
CONTINUOUS INTEGRATION AND DELIVERY/DEPLOYMENT
One of the coolest processes a tool like Git opens up for you, especially when using something like Gitlab, is CI/CD (continuous integration and continuous delivery/deployment). Automating what can be the most time consuming and stressful part of the software development life cycle (SDLC) is what makes platforms like Gitlab and Github so powerful and your version control system is the backbone of all those processes.
Git is an important part of my toolset and I firmly believe that it should be used by every person writing code, whether it’s for applications or for infrastructure. If you’re new to Git or you haven’t even heard of it, Gitlab has a great write-up on getting started with Git.
If you have any questions around version control, Git, CI/CD or even Gitlab, reach out to me on Twitter or LinkedIn and I’ll gladly answer any questions. Feel free to let me know where I can improve this post as well.
