Git & the impact on software development

In this article:
Subscribe to our blog:

Computers have only been around for a short while, but a lot has already happened. While there has been milestones along the way (eg the internet, smartphones and social media) the advent of Git truly impacts developers.

This is especially key as software development, like much of technology, is highly susceptible to change. It seems every couple of years there’s a new, hip, programming language, framework or concept that has thousands of developers flocking to work with it. Of the tech trends that stick, 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 this wasn’t always the case.

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 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. Even Mercurial, 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 came 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 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.

Now developers 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, server 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 Git had other things going for it as well. The fact it was created by Torvalds, an influential developer with a large following, has definitely helped its adoption rate — but there was was one more thing contributing 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 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 quite obvious when talking to new programmers, who often mix them up or think they’re the same thing. The most important thing, however, is 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


Codacy is used by thousands of developers to analyze billions of lines of code every day!

Getting started is easy – and free! Just use your  GitHub, Bitbucket or Google account to sign up.

GET STARTED

RELATED
BLOG POSTS

7 Best Practices: Working with Freelancers & Outsourced Developers
Freelancers and outsourced developers have become more regular parts of the team for many using Codacy. There are some best practices we learned to...
Open pull request: what would happened if you merged all open PR?
We really don’t know what would happen if we merged all open pull request (PR).
10 facts about code review quality
This is a short and sweet story about important facts to know and share about code review quality. Join the discussion on reddit and hacker news.

Automate code
reviews on your commits and pull request

Group 13