Developer Skills You Must Know (But Didn't Learn in College) | Part 1: Version Control

On March 22nd I gave a presentation to ASU's Software Developers Association which I called "What My Professors Didn't Teach Me - Developer Skills: What They Are, Why They're Important and What You Should Know About Them". The presentation provided an overview on seven different "developer skills" that I believe are necessary to succeed as a professional software developer. I define "developer skills" as those aptitudes between the "hard" technical skills of programming / hacking and the "soft" interpersonal skills of teamwork and communication. They are the things that a developer needs to know to succeed at his job outside of actually building software.

Over the next several weeks I will be writing a post on each of these proficiencies; each post will describe what the developer skill is, why I consider it to be necessary knowledge for the workplace, and what specific things you should learn. I plan to have links to tutorials or other websites that you can use to follow up.

The first three topics in this series - version control, ticketing software, and the multi-branch development workflow, all fall under the umbrella topic of "codebase management technology". I consider these prime examples of developer skills, seeing as they very much involve technical subject matter, but in the context of working with other people - your workplace's development team.

Version control is the first of these, and that is the topic this post will be dedicated to.

At a high level, version control refers both to the practice of tracking changes to your codebase, and the software that is used to do this tracking. At its most basic, version control allows you to keep track of your codebase's history, so that you can go back and see what changes were made at what time.

Tracking the history of a file with version control

That being said, version control has many more features beyond this, which make it a necessity for modern development. These features include:

Branching and Merging:

Version control software allows you to "fork" a codebase into two "branches". These branches share a common history up to the point at which they were forked, but after that, different changes may be made to each branch. Furthermore, version control software allows you to "merge" one branch onto another, such that the latter branch now contains both its own code / history plus that of the former branch.

Branching turns one history into two...

...and merging combines them back into one

Branching is conceptually quite straightforward - it's like making a copy of your codebase - but merging is a bit more complex. How can two histories become one? Imagine two copies of the same codebase - you make a few changes to one, then a few different changes to the other. Those changes are ordinally related despite happening in two different places - so version control simply does its best to bring both sets of changes together and reconcile the history to reflect the order in which things really happened. Note that certain changes might be incompatable - if you make different changes to the exact same line in a file, for example - in which case the software won't be able to automatically merge and will require manual intervention. Fortunately, the software usually has utilities to help with this as well.

After merging in the previous image, the history of the merged branch will look like this - as if it was one branch all along.

Branching and merging powers many other powerful version control features, one of which is:

Remote and Local Branches:

By default, version control is all run off your computer - all branches live within your "local repository" (just another word for a collection of branches). However, most version control softwares support linking to "remote" repositores stored on other computers, or on servers on the internet - allowing you to "clone" remote branches to create a local copy of that branch, "track" remote branchces and "pull" remote changes into your local copy, and even "push" your own local changes back to a remote branch. Note that all of these are really just different ways of merging the two branches.

The local branch is cloned from the remote branch, changes are made, and then pushed back to the remote.

One obvious application of this is using remote branches as an external backup of your codebase - you make all your changes locally and periodically push them to the remote, thereby backing your code up. Indeed, this is one of the most important features that version control provides.

Another of these important features is:

Multi-User Development:

This is perhaps the most powerful use of version control - it facilitiates and smooths the interactions between a team of developers all working on the same codebase. This usually takes the form of a central remote repository with local branches for each dev. Each dev makes his changes locally, then merges it to the remote repository, which other devs then pull down to their own locals.

Each user has their own local branch and can make changes locally, which are then pushed back to the remote branch.

Anyone who has tried to handle multiple developers working on the same codebase without using version control can likely see how difficult this is - two people can't work on the same file at the same time, it's very easy to overwrite somebody's changes accidentally, and if one dev breaks the build, everybody else has to stop working until it's fixed. Version control solves all of these problems.

I've highlighted here a few of the major features of version control, but this is by no means all of them. Hopefully, however, this gives a feel for what version control does.

Why Is This Important?

It's tough to declare universals about any careers, much less one as varied as software development; that said, I'll do it anyways. All the dev shops worth working at today use version control. It is indispensible, and in many cases, it's the only way that other codebase management processes can be powered. I might even venture to say that this is a prerequisite to being hired these days - a resume without version control knowledge is a weak resume indeed.

The benefits of version control were discussed above, but to make them explicit, they are:

Enforces backup - I don't think I need to explain how important having backups are for professional developing.

Allows a team to easily collaborate on a single codebase - unless you're the only developer, then this feature alone makes version control necessary.

Version control tracks the history of a codebase, which can be very important in a professional setting - it gives you a built-in way to track which decisions were made, and if something goes wrong, it allows you to quickly figure out who introduced the error. Yes, this is important in a professional setting.

The branching and merging feature powers something I have not yet discussed - the multi-branch development workflow. This will be the subject of a different post, but for now, sufficient to say, it is important.

It's not impossible to get hired without version control knowledge, but it's a skill that will look good on any resume. Furthermore, until you know how to work with it, you likely will not even be able to get at the codebase in your new job.

This is important - so what exactly do you need to know?

Things You Should Know:

What's the best way to go about learning how version control works? As with many things in software development, I recommend simply learning a version control system. There are a handful of different ones, but they're mostly similar, so once you know one you'll pretty much know them all.

The software I recommend learning is Git. Git is probably the most widely used version control software at this time - certainly this is the case in web development. Git is also neat due to Github, a website that hosts free public Git repositories for anyone who wants one. The Git software itself is also free - so you can set up a full remote / local repository system without paying a cent.

There are many different online resources (again, free!) that will help you learn Git. Some of these are:

These classes will give you both a general feel for how version control works, as well as teach you the specific commands that you use to work with Git repositories. The latter is important, but the former is critical - ultimately, you need to understand version control concepts to really use the software effectively.

The major concepts I recommend you know:

Understand how branching and merging works. Especially understand how merging "combines" histories - this is very important for troubleshooting.

Understand how to work with both remote and local branches.

Understand how to handle merge conflicts - if you run into problems with version control, it's almost certainly going to be a merge conflict. They're going to happen, so know how to handle them.

Conclusion:

That concludes the first of the seven developer skills. I've placed this one first because, in my opinion, it's probably the most important - certainly, it's the most important of the first three.

Version control is not terribly difficult to learn - especially with the many resources that are out there. I encourage you to open up one of those links in the previous section and start learning tonight! I'll be back next week with the second post in this series, on the topic of ticketing software.