How Git Changed The History of Software Version Control

By Juan Buis

Disclosure: Codacy, the automated code reviews platform, has previously sponsored Hacker Noon. Use code HACKERNOON for 15% discount. This post originally appeared on the Codacy Blog.

Computers have only been around for a short while, but a lot has already happened. Along the way, there have been a couple of unmissable milestones — just think about the advent of the internet, the commercial success of smartphones and the current omnipresence of social media.

Some of the progress, however, has happened far away from the limelight. These things might not have been interesting for the masses, but they’ve been instrumental in shaping how we use technology today.

Software development might be the single thing in technology that’s the most susceptible to change. Every couple of years it seems like there’s a new, hip, programming language, framework or concept that has thousands of developers flocking to work with it. Only a couple of these actually stick, of course, and Git has definitely been one of them.

Today, it’s the single most-used version control system out there, and its influence is hard to overstate. But before we get down to Git, it’s vital to understand how the concept of version control came to be, and why it’s so important to the current state of software development.

VCS: an abridged history

Computers have grown to become very friendly machines. If you mess up and accidentally delete a couple of paragraphs from an important document, there’s no reason to panic — you just hit undo. But it hasn’t always been like this.

Way back in the early days of the digital revolution, most people hadn’t even heard of computers — but the ones who did had a much harder time using them. Software developers at the time didn’t have access to a version control system, and instead worked with a single person who owned the master version of a project. This person would only share the specific part of the code someone needed to work on, a developer would return the finished code and finally everything was checked for standards before the old version was fully replaced by the new version.

All in all, it was quite a tedious process. Unless someone actively made recurring copies, there wasn’t easy access to previous versions. Until one day in 1972, when developer Marc Rochkind couldn’t deal with it anymore. He ended up creating Source Code Control System (SCCS), the very first version control system. It was pretty limited in functionality — only one person could be working on a file at a time and concurrent development was managed with locks. However, it also solved a lot of problems — multiple versions didn’t need to take up large amounts of disk space anymore, and merging optimizations became a lot easier.

The second generation of VCS consisted of tools like CVS and came with improvements across the board. In general, they gave users a lot more flexibility, but one thing remained — revisions needed to be merged before they could be committed. It was time to solve this problem and take version control into a new age.

Git: a rising star

Soon after, the industry found itself at the dawn of third-generation VCSs, which were the first to separate merging and committing. These so-called distributed version control systems were aimed at improving speed, data integrity and supporting distributed, non-linear workflows.

At the forefront of this wave of systems was Git, a DVCS invented by Linux co-creator Linus Torvalds. When it was first released in 2005, most people were still using Apache Subversion (SVN), but over the course of the next decade the two became entangled in a browser war of sorts. Today, Git has grown into the leading versioning tool. EvenMercurial, its most popular third-generation competitor, lags far behind in terms of usage.

Why Git is great

So why did Git become so widely adopted, and how did it grow into the first choice of today’s developers? Mostly because it was an enormous step forward for version control.

1. Git is distributed

This is by far the biggest and most important difference between Git and everything that became before it. Instead of depending on a centralized server, people were now able to commit, log and do anything else locally, in real-time without having to use a VPN or even be online. Suddenly, it was much easier for people to work together remotely — even across time zones. It also meant that in the case of an emergency the source data wouldn’t be lost like in the past, as everyone effectively had a full copy on their local drive they could push to the server.

Also, developers now had access to much more flexible workflows. Git can work with multiple repositories and synchronize changes between them, which opened a world of possibilities. For example, you could limit someone’s write access to specific repositories, so a manager can check their work before merging it into a central repository

2. Git redefines branching and merging

While branches did exist in second-generation VCSs, the way they worked made them much more cumbersome. In Git, they’re key elements of the system and work flawlessly — for example, creating a branch happens locally and instantly. Depending on your internet connection, the server’s status and other factors, this would’ve taken much longer in a centrally-managed VCS like Subversion. This fast way of working makes it easy to create a quick branch for any ideas you have, so you can later decide if you want to actually add them to the master or throw them out.

Git also handles merges much more gracefully than previous systems. Because it uses a different way of recording commit history it’s able to remember everything that has already merged, significantly decreasing the number of conflicts that occur.

3. Git has a staging area

Another great feature of Git is one that has made a lot of lives easier. While previous VCSs required users to commit all changes at the same time, the staging area makes it possible to split all work into multiple changesets. When these are staged and committed individually, it makes it quicker for others to figure out the structure of what you’ve been doing.

4. Git had the best marketing campaign

Even though it’s a stellar system in its own right, it’s hard to deny that Git had other things going for it as well. The fact that is was created by Torvalds, an influential developer with a large following, has definitely helped its adoption rate — but there was was one more thing that contributed a lot to the success.

GitHub: the hidden motor

When talking about Git, it’s impossible to skip over GitHub — one of the driving forces behind the system’s popularity, and also a big influence on technology in itself.

At the time of its launch in 2008, Sourceforge was the default way for open-source developers to share projects — but nobody really liked it. The service was full of ads, and it generally offered a terrible user experience. In comparison, GitHub felt like a breath of fresh air — mostly because it was actually good. When the company announced that hosting for open source code was going to be free, everyone started using it for their personal projects, and this popularity bled over into the professional industry over time.

It quickly became the go-to hosting service for Git, offering all of its standard features and adding new ones on top. It effectively turned the DCVS into a social network by adding features like user profiles, public repositories and pull requests, which created a unique community of coders. Eventually, it grew to become the world’s leading codesharing platform where millions of developers collaborate on all kinds of projects.

Over the years, Git and GitHub have profited a lot from each other’s growth. This is something that becomes obvious when talking to new programmers, who often mix them up or think they’re the same thing. The most important thing, however, is that their combination has been a huge step forward for software development, simplifying and enhancing the way we’re building the applications of the future — and that’s a trick that isn’t easy to pull.

Discover more on Github Code Review