It’s hard to imagine software development without version control, whether it’s Subversion, TFS or Git. These tools — also known as source control systems — track old versions of code and allow developers to collaborate without overwriting each other’s work.
Version control software is also a prerequisite for many of the processes pushing software development forward. Automated deployments and collaborative open source projects are built on a foundation of version control.
Version Control, Explained
When I used Microsoft Word to write papers for class back in school, I would sometimes save an extra copy of the file right before making a big and potentially disastrous revision. It was a guarantee that, if I screwed up really badly and couldn’t remember how to put it back together, I could always open the old version and pick up where I left off.
As it turns out, developers like to have that reassurance too, but source code is far more complicated than Word documents. Projects often include hundreds of files, so trying to manage copies of all those files manually while not breaking the project would be effectively impossible.
What Is Version Control Software?
So developers have built entire software systems to support their version control efforts, and these systems now underpin how the entire process of writing and deploying code is handled. All you have to do is create a name and a description of the copy, and version control manages all the relationships between copies for you.
“You have that instant Time Machine, ‘put the code back the way it was three days ago’ feature, which is really handy,” said Brian Coords, technology director at Howard Development and Consulting. “If something broke on Monday, you can reset the code all the way back to Sunday immediately because you can just roll back to those previous versions.”
Version Control Lets Developers Dive Into Code Histories
The heart of these tools is versioning — tracking changes throughout the lifetime of a project.
Developers can “check in” the code they’re working on into version control at any time, and also “check out” any versions that have been checked in before. Any of these versions can be viewed in a code editor and run just like regular code.
Developers sometimes check in code more often when working on particularly tricky parts of the codebase. That way, if something breaks, it’s easy to compare changes to the last stable version and pinpoint the problem.
“Six months or one year down the line, sometimes you don’t remember everything.”
Cindy Potvin, a developer based in Montreal, said it’s also just useful to see how changes in code progressed. Instead of relying on memory and documentation, both of which can be spotty, developers can pull up code directly to help with tasks like debugging.
“There are parts of the codebase I’m working on that are from the ’90s,” Potvin said. “I know some people have very good memories, but six months or one year down the line, sometimes you don’t remember everything.”
It’s especially easy to lose track of what each line of code is doing in legacy projects with complex business logic. Potvin said, in those cases, it can help to read the description on each saved version of code — usually the description includes the issue that version addresses, which can provide helpful pointers about what changed, and why.
Version Control Strengthens Team Collaboration
Even a single developer working alone can benefit from the ability to keep track of code histories, but version control is even more important for teams.
A solo developer might remember how every line of code was introduced to the codebase, especially when working on a small project. But each new person added to a project makes it more difficult for individual developers to stay on top of all the changes being made. Version control can help untangle who did what at any point in time, and give a clearer picture of how coding decisions were made.
“Every time I do a commit, it shows me the changes I made,” said Rob Howard, CEO of Howard Development and Consulting. “If you imagine months of development happening, it’s almost like a note-keeping system. Here’s what I did, and then I can look at what Brian did, and I can compare the two or see which files changed and didn’t change at any given moment.”
This is especially useful for highly collaborative teams whose developers are in the habit of passing work back and forth. Developers beginning work on a new section of code can go through version control logs and see its most recent changes.
“If we did not have version control, we would just be overwriting each other constantly.”
Version control also makes branching possible. Branches are copies of the working code that let developers work on different features at the same time. They’re the same as copies, except there is usually one main branch that all developers agree to make “feature branches” from. Multiple feature branches are often active in a codebase, with different developers working on each one.
Once work on a feature branch is completed, it gets “merged” back into the main branch on a line-by-line basis. There are occasionally “conflicts” due to multiple developers changing the same lines of code and trying to merge into the main branch, which can be resolved manually by developers in their code editors.
Branches make it “possible to work simultaneously on the same codebase without interfering with one another,” Howard said. “If we did not have version control, we would just be overwriting each other constantly, and it would be a mess and impossible to keep track of.”
A Much Better Alternative to FTP
Version control’s main functions — keeping code histories and allowing simultaneous work on the same code — are foundational to how DevOps processes work. DevOps coordinates the complex process of packaging up code and moving it from the development to the production environments, and the first step is always grabbing the code from version control. Otherwise, developers would still be moving code from their laptops to the production server by hand.
“You would use file transfer protocol, which is the ability to just manually upload files,” Howard said. “So it basically looks like a file manager where the left side is your computer and the right side is the destination server. And you would be essentially dragging and dropping stuff to upload everything.”
Even with automated DevOps processes and version control, it’s still possible to release code manually, but that approach leaves a lot of room for error. Enabling developers to kick off an automated DevOps process erases the need to remember all the obscure quirks of a project’s release requirements. It makes it possible to run tests as part of every release, and to have code configured differently depending on whether it’s being pushed to the development, test or production servers.
“It’s more cumbersome,” Howard said about manual releases. “It’s on you to remember what changed. ... If I’m sending it to two or three places, I need to then repeat that process.”
Version control also makes it possible to do pull requests. Pull requests play an important role in fostering close collaboration within development teams and even between developer groups within a large company. Instead of each developer being left alone to work on their feature, pull requests make sure that other developers have a chance to review everything being worked on before it’s merged into the codebase.
There Are Many Different Types of Source Control
When people talk about version control, they’re usually referring to tools like GitHub. But those tools are really wrappers around the actual version control system — Git, for instance.
Tools such as GitHub and Bitbucket “essentially create a layer on top of Git that makes it way easier to manage and see visually,” Howard said. “Git is the underlying software that actually handles the tracking of the files and the changes to the files.”
Git is one of the most popular version control systems. It’s distributed, which means developers have complete local copies of each code repository they are working on. Potvin said distributed systems give developers more flexibility with how they choose to use source control — but that can be a mixed blessing.
“Distributed is a bit harder to understand when you’re not used to that way of working,” she said. “We’re switching to it at work, and I have experienced it in other contexts, but it’s a different way of thinking.... It’s a lot more fluid.”
“Distributed is a bit harder to understand when you’re not used to that way of working.”
Developers have a lot of control over how to use and manipulate Git, and its fluidity also encourages innovation and taking full advantage of version control’s offerings. But that system is also notorious for tying developers up in knots — usually when they’re trying a new Git operation they thought would be really neat and save them time.
There are also centralized and local version control systems. Subversion is a popular centralized system — developers using a centralized system check out small portions of repositories to work on from remote servers.
Potvin considers centralized version control systems more straightforward for developers to understand. But it has a top-down approach that discourages some developers from using source control to work more collaboratively with team members.
“With a centralized approach, it’s a lot more shared with everyone,” Potvin said. “The process of starting a branch and merging it back can be a lot more complex. Some people don’t even branch because it’s a pain.”
The last category, local version control, stores all copies of code on an individual developer’s own computer. This method is able to manage versioning and histories, but it doesn’t help developers collaborate with team members.
Should You Use an Established Version Control Service, or Build Your Own?
Git is an open-source system — as is Subversion — and developers can build their own version control without using a service like GitHub or Bitbucket. Some developers like to do so, and manage their own systems because of concerns over privacy, a desire to create more unique functionality — or simply out of a desire to hack everything themselves.
But using these services built on top of version control systems can provide rich functionality for developers. They can make version control easier to use, and they add many capabilities that developers would otherwise have to piece together themselves.
“They essentially act as the middleman,” Howard said. “As opposed to us having to establish our own Git server, they have their system. They do a really good job with it — they keep it up to date, they keep it secure, and they kind of take that work off of our hands.”
One of the most important features these services provide is a user interface. Without a UI, developers would have to interact with their version control using only the command line, which makes it difficult to do things like code reviews on pull requests. These tools also help tie in the DevOps capabilities that are dependent on version control.
“They keep it up to date, they keep it secure, and they kind of take that work off of our hands.”
“You could say, ‘Every time I have new code, do these extra things for me, and I don’t have to do them manually: test the code, or review it, or deploy it somewhere so I can see it,’” Coords said. “Those sorts of things you’re relying on that service layer to do for you.”
Howard’s development team has also set up its repository in Bitbucket to send Slack notifications whenever developers push new code.
“You basically have a live stream of what’s happening on Bitbucket,” Howard said. “And there’s 1,000 other possible ways you can integrate it. You now have that data of what’s happening in your repository, and it can be sent out to any destination.”
Developers created version control software to help manage backups, and it grew to become much more than that, with developers adding functionality such as branching and merging. Now developers are building more and more functionality into version control services — it seems a shame not to take advantage and see where it leads.
