Dear Students: Learn Version-Control
Hit the ground running at your first job
I’ve been working as a coder for (almost) twenty of your finest, British years now, and I am sometimes asked what the number one lesson I would impart to the younger generation seeking to break into ‘the industry’ is.
Here it is: Learn Version Control.
I wasn’t taught it at university, and I didn’t know it was ‘something I should know’ until Day 1 of My First Real Programming Job, when I was suddenly thrust in front of a computer and told to ‘check out the codebase’.
This was not, I quickly came to discover, an exhortation to be impressed at the genius of my predecessors, but was instead a very specifically phrased instruction to sign into the VCS (Version Control System), download the code, and get to work.
Thankfully, my supervisor was patient and understanding, and got me up to speed relatively quickly with their VCS - but not everybody has someone so patient as their first manager, and not every business is willing or able to spend time teaching new hires something so fundamental.
In this post, I’ll cover some (very) high-level basics about version control systems in general, so you can be armed and ready for your next interview!
The Wall
Though I don’t recall being taught anything even vaguely related to version control at university, I am willing to concede that as a student, I was not the best listener. It’s entirely possible that it was mentioned, maybe even repeatedly so, but it was certainly never treated as a fundamental concept, and I was never required or encouraged to use it during practical exercises. When code needed to be shared or moved around, it was done on a USB stick, or via email, and ‘different versions’ of the code were managed through the advanced wizardry of copy & paste to a new folder. This process was ‘how it was done’ for the entire duration of my university education. Even our professors would simply send us ZIP files over email!
This was, to put it bluntly, entirely unrepresentative of the industry: I have never, in all my years, worked at any development studio that didn’t use version control as standard. In contrast, I have repeatedly hired people fresh out of university who have never even heard of version control.
In the best cases, this is quickly rectified: once a person grasps the basic concepts, one version-control system is much like any other, and even basic usage is usually enough to convey the benefits, so it quickly becomes another part of the toolkit.
In the worst cases, however, the sudden introduction of a VCS is a barrier to entry that can cause people significant distress when their job depends on it. I’ve seen new hires literally start to cry when they realise that something they will be doing every day for the rest of their careers has been entirely omitted from their education. Without wanting to be overly critical of our educational institutions, it is alarming how frequently I’ve seen people hit this wall - and what makes it worse is that the core responsibilities and workflows of most popular version control systems can be taught in an afternoon!
Outside of formal education and employment, I’ve seen countless examples of aspiring programmers and game developers take to Reddit and other forums asking questions like:
How do I work on my project with my friend?
What’s the best way to back up my project?
My codebase is a mess and I can’t keep track of it all - how do you do it?
And, worst of all:
Help! My hard drive died and I’ve lost my work - what can I do?
The first, last, and best answer to all of these questions is: Learn Version Control.
The Basics
Regardless of which specific sector of the industry you’re aiming for, it is almost a cast-iron guarantee that you will be expected to use version control day in, day out. Whether you’re building software for financial institutions or making the next AAA game, version control will be a fundamental part of the process, and one that is not limited to coders. Artists, writers, and audio designers also need to engage with the VCS as part of their standard workflow, and at the highest level, the VCS is what enables each different discipline to share their output with the rest of the team.
Of course, different specialisms have different needs, and different companies have different workflows and processes. Though the core concepts of most version control systems are similar, and the knowledge required to use them is largely transferrable, some systems are specialised towards particular sectors and disciplines, whilst others try to generalise to suit the needs of the industry more broadly.
There are several basic ideas that every version control system incorporates, although the specific terminology and workflow may differ.
At the most abstract level, every VCS allows you to do the following:
Download a copy of the files you need to work on
Edit those files
Add or remove files
Make your modified, added, or removed files accessible to others
See the history of any file within the system
Roll back files to previous versions
With the above core features, a single developer may cast off their anxieties and learn to code with confidence, safe in the knowledge that they can move backwards and forwards in time, and that they can store snapshots of their work as and when they see fit. A team of developers becomes an unstoppable force of nature, sharing their work early and receiving feedback and support as they go.
One point worth keeping in mind: version control can add a lot of security and confidence to a project even with a solo developer, but it is not, on its own, a backup until a copy of the code is located somewhere other than your own machine! Most VCS options will make this process straightforward, but if you don’t want your code to be publicly available, and depending on the VCS you choose, you may find you need to pay for remote hosting of your repository.
Not A Robot is a reader-supported publication, but a subscription is not for everyone. If you’d like to support my work without a monthly commitment, click below!
Fear of Commitment
One of the most revelatory concepts any developer discovers when they first engage with a VCS is that of fearless coding. Without a VCS, developers need to worry about whether the changes they’re making are appropriate for the problem at hand, and run the risk of spending so long fiddling with one area of code that they forget what it looked like before they started.
Unless they have an extraordinary memory, developers can resort to all kinds of messy workflows in order to maintain their ability to undo their changes or refer to the original code whilst making modifications.
With a VCS, this issue is largely eradicated. Developers can create a snapshot of their work whenever they choose, and, if so inclined, commit those changes so that everyone else can see them.
The specific workflow around this process is different depending on the VCS in question, but the effect is largely the same: a developer can decide to commit their work at lunchtime, get away from their desk, and then later review the state of the code at the previous commit in order to refresh their memory before continuing.
The ability to work in this snapshot-driven way means that developers don’t need to keep the entire system in their heads at all times, and can freely make changes safe in the knowledge that they can always roll back their commits if they identify a better solution. Typically, each time a developer commits new work, the VCS will prompt them to write a brief message describing the work they’ve done. This message forms part of the overall log for the code-base, and allows developers to navigate the history of a project with ease.
Alternate Universes
Aside from the basic functionality of adding, modifying, and sharing files, one of the most powerful concepts within a version control system is that of the ‘branch’.
A branch is effectively a snapshot of the codebase taken from a particular point in time, which allows the developer to work from that starting point and build up a parallel timeline to the main development branch.
This allows features to be worked on in isolation, and for speculative changes to be made which might otherwise cause disruption or risk for other ongoing work.
In some version-control workflows, branches are incredibly common, and may be exploited for even the smallest change. In others, branches may be less commonly utilised, but the underlying principle remains the same: a branch is an alternative version of the codebase and associated history.
In commercial development, regardless of the specific sector, it’s critical that developers can adapt to new requirements and circumstances, or fix an issue in a shipped version of the software without being forced to release unfinished features. Branches facilitate this flexibility and adaptability, and are likely to be a regular feature in most developer’s day-to-day work.
Merging Realities
As any good developer knows, the only real source of truth in any software project is the code itself.
When you’re dealing with branches, however, we regularly need to bring one branch up to date with all of the changes in another. Bringing two branches into alignment is known as merging, and we typically talk about this as ‘Merging Branch B into Branch A’.
In the ideal scenario, this goes smoothly, but in some cases, two branches cannot merge cleanly because developers may have modified the same files in the same place in both branches, and the system doesn’t know how to reconcile the differences.
This is known as a conflict, and it usually requires manual intervention to fix. Typically, we use a merge tool to resolve these issues: this allows us to view the differences between the file in Branch A, and the same file in Branch B.
In the above scenario, we’ve modified the last line of the file in both branches, so we need to choose whether to accept the changes on the left hand side (the ‘incoming’ changes), or the changes on the right hand side (the ‘local’ changes). Alternatively, we can select neither change, and just hand-modify the merged file to resolve the issue.
The bottom panel shows the state of the merged file. The merge tool you end up using may look different to this, but the basic functionality will be similar.
It’s worth keeping in mind that some files cannot be merged in this manner. Binary files (images, audio etc) generally require somebody to identify the ‘correct’ version.
Even in the case where a merge goes smoothly, it’s always best practice to ensure that the work from both-branches remains as-expected and no issues have been introduced as a result of the merge.
Pax Automatica
A version control system is often paired with a suite of tools that provide a degree of automation to certain processes and workflows. At the highest level, this kind of setup is often referred to as a ‘Continuous Integration’ (CI) system, but the specific job(s) of such a system will vary dramatically based on context.
Such a system is frequently configured to respond to events within the VCS and to trigger some automated processes to execute as a result.
For example, when a user adds a new feature to the codebase, the CI system may:
Run a set of automated tests
If any test fails, the developer may receive an email or other notification alerting them to the problem
Compile the code and store the built version of the application somewhere.
Deploy the new version of the software to a device or server for user testing.
Typically, these systems will be maintained by more senior colleagues, but being aware of their existence and what they can do for you is a great way to avoid panic or anxiety about making changes to the codebase.
A robust CI system can dramatically improve the stability of a codebase, and reduce turnaround times for new features and fixes. Automated reporting of test results and build times allow developers and production staff to ensure that work is progressing smoothly, and to receive early warnings about potential problems before they become too serious.
When used effectively, a CI system improves the confidence and flexibility of the development team, and allows the organisation as a whole to take a great degree of pressure off the workforce.
Some VCS Options
There are a variety of different VCS options available, and it’s likely that your first employer will have built an entire infrastructure around whichever one they use.
One of the most popular version control systems used today is Git. It has a very small footprint and is a distributed VCS, which means it doesn’t require a central server to act as the main entry point or authority. Git is quite happy for two developers to push and pull changes to one another directly on their development machines, but in most practical commercial use cases, people still choose to host a central repository, which allows tighter security and easier control over access and permissions.
Alternatives you’re likely to come across include:
Interview Questions
When it comes time to start job hunting, demonstrating knowledge and experience around version control systems and practices will help to set you apart from the competition.
In an interview for a role, showing an interest in a prospective employer’s version-control system and workflows shows that you’re looking at the bigger picture and that you wish to understand how the organisation functions beyond the immediate scope of the role you’ve applied for.
Some questions you might wish to ask:
Which version control system do they use?
Some employers might not wish to divulge specifics around this depending on their security practices and concerns, but many will be happy to oblige.
Why did they choose <x> as opposed to <y>?
This demonstrates a wider base of knowledge around VCS systems in general, and their answer may reveal useful information about how they work and what their practices are which you can then build upon.
What does their review process look like?
In many organisations, this process is intrinsically tied to the VCS in one form or another, and code reviews are often oriented around pending merges.
Do they use a Continuous Integration / Automation system alongside their VCS and if so, what kind of benefits have they seen?
Any organisation seeking to continuously improve is likely to be constantly tinkering with their CI systems to add extra functionality or to provide more robust checks and reporting.
Summary
Whatever your goals are within the world of development, a VCS is a hugely beneficial tool for any project.
In a commercial development environment, the idea of developing any serious project without a VCS is unthinkable, and so the more confident you are and the more experience you have in this area, the more favourable you will appear to prospective employers.
If you’re currently working on a project in the hopes of bolstering your portfolio, and it’s not already under version control, then please heed this advice and start using a VCS at the earliest opportunity!
Of course, lack of experience with a VCS may not be the thing that prevents you from landing your first dream role - most good employers acknowledge that experience is gained over time, and are more likely interested in your coding skills and your overall attitude - but you will be using a VCS if you get that job, so familiarising yourself as soon as possible will only increase your chances and smooth out the onboarding process when you do get hired!
Further Reading
If you’ve found this post useful, you might like to read one of the following:
This is an excellent introduction to version control, Tom. It is definitely something I overlooked during my years as a Computer Science student, and I had to catch up when I got my first job as a software engineer.