Version Control
I’ve been working as a software engineer for over a decade. In my time I’ve worked on projects that had version control in place and projects that had no version control. While I believe all projects should use version control, I have come across some projects that don’t see the benefits or value. This article aims to highlight the benefits and value from using version control and the pitfalls of no version control.
What Is It?
First, what is version control? It’s essentially a library for your code with a specialized database tracking all changes to any file. This type of tracking provides insight into your code in terms of changes, thoughts about changes in the form of comments, and overall visibility into how your code changes over time. It also allows using your entire code base at any single change. This becomes helpful if a breaking change is introduced to your code, you can always roll back to a previous version. It also helps your developers identify the exact change that introduced a bug.
Why Use It?
As mentioned, it does provide some innate capabilities like rolling back to a previous version and viewing changes to code. It also handles complicated code merges in the event 2 people change the same code. This type of code merging makes things easier and faster over teams that do not utilize version control systems. Take an example I’ve experienced in the past during my early years as a software engineer:
The team was small (3 people) and the project was simple (a simple website). This was the days of FTP clients and deploying your website was accomplished by drag-and-drop to your web server. Simple. Easy. Clean. Right?
Well, with 3 developers we decided that the web server would be the stand in for the most current version of the website (after all, it’s what everyone on the internet was looking at). Things immediately became more complicated. If a developer was working on something, they first needed to copy the files from the web server to their local machine, make their changes, then copy the files back to the web server. Hopefully no other changes were made in the meantime. When changes were made (and the most definitely were) the developer would have to copy the files from the web server (again) back to their local machine (in a different folder), talk to the developer (or developers) that made changes to figure out what they changed, and manually merge changes in those files affected (timestamps definitely helped). When that was all done, they would have to the web server again for changes. Sometimes, more changes were present and the whole process of copying, talking, and merging needed to occur again. This cycle repeated itself until the timing of being ready to copy to the web server and no changes on the web server aligned. This could take a few hours.
We were naive of version control systems at the time. Once we discovered one (Subversion in this case) it made things infinitely easier. Developers would check out the main branch of the repository, make their changes, then check them in. Merging happened automatically most times unless 2 developers were working on the same code. In this case, the source control manager would present the conflicting changes in an easily readable visual manner and allow the developer to pick and choose what the final file would be. After this merge, the developer could test the changes before committing everything back to the repository. If a developer made changes before the commit was ready, the source control manager knew and the developer would update their code from the repository. Again, merges generally happened automatically at this point, but in the rare case a conflict would arise and the visualizer would present this conflict to the developer. This cycle rarely happened because the whole process was fast, easy, and efficient. When a deployment was ready, a tag was made in the repository and that specific tag was checked out on the web server. No file copies were made any more, no FTP clients were involved, and everyone knew exactly what was on the web server at any given time and if any of the files on the web server had changed.
Wrap Up
I find version control systems a necessity for a successful software development team both in terms of efficiency and cost. Less time working on frivolous things equals less money spent! If a team insists on not using a source control manager, maybe that team hasn’t yet experienced anything negative impacting their development efficiency. I use source control for all of my projects regardless of team size. It’s beneficial for a team of 1 just for the ease of code tracking and visibility into bug introduction. If you’re not using source control, I strongly urge you to adopt it!