Git has been around since 2006 when it was created by Linus Torvalds, the same mind behind Linux. Between 2006 and the present, Git has become the dominant version control system (VCS) used in software development, dwarfing others such as Mercurial, Subversion, BitKeeper, Darcs, and a plethora of lesser known tools. It’s a good bet that if you write code and have ever collaborated with another developer, Git is the VCS that you use.
As we move into 2021, Git remains relevant for a variety of reasons and likely to maintain its dominance for quite some time, as I’ll show you in this post. Git is a major part of a developer’s routine, and being informed about its current and possible future trends is important to one’s career.
Git’s Current Dominance
The strongest driving factor for Git’s present relevance is simply the fact that it is already the version control system of choice for the vast majority of developers. This means that individual developers, indie teams, academic users, and industry departments will continue to choose it, since that is what the developer community and talent pool is familiar with. The strong get stronger, and the weaker tools fade out of the mainstream.
It also means that teams who have been slow to adopt newer technologies like Git will continue to make the shift, likely at an increasing rate. There are many teams that still operate on more legacy centralized VCS tools like Subversion. This is likely because their organizations have been rooted in that system for many years.
However, more and more of them will be forced by economic factors to upgrade to Git. This is because Git provides more flexible collaboration workflows, and a larger share of their technical employees will be familiar with it. As we’ll see later, it is also extremely easy to migrate to Git a codebase previously tracked with a different tool.
Git’s Brand
The second most powerful predictor of Git’s continued relevance is its brand. When people think of version control and tracking code, they instantly think of Git. Even non-developers are familiar with code hosting sites like GitHub and BitBucket. GitHub especially is in the mainstream eye and consciousness.
A strong brand is important because it allows people in the world to recognize a product or service, participate in the narratives surrounding it, and help influence others to use it. It also allows the product or service to be associated with contextually relevant topics—in this case software development, programming, and collaboration.
This is especially true in our times, where so much influence is driven by Google’s algorithms and crawlers, driving traffic between associated topics. Git is like the Coca-Cola of version control. Ultimately, its brand will help it further engrain existing users while attracting new developers every day.
The Ease of Switching to Git
As I previously mentioned, users knowing about Git and wanting to switch to Git are one thing, but there needs to be a straightforward pathway for migrating legacy projects to Git. Luckily, Git provides thorough documentation for migrating from other systems.
The above guide contains steps on how to migrate code repositories to Git from Subversion (SVN), Mercurial, Bazaar, and Perforce.
Essentially, for each system, Git has a subcommand that allows interaction with that source system. For example, the git svn <subcommand> command set is used to interact with Subversion repositories. Think of each of these commands as a translator between the source system and Git’s backend.
Git even provides a custom importer that you can use to migrate your project from other systems that Git doesn’t support out of the box.
Git’s Minimum Viable Use Case
In general, version control can be a tricky topic for new developers to grasp as they learn programming. It isn’t the most intuitive set of concepts to learn, and it takes real-world practice on a couple of projects before getting the hang of it.
However, in my opinion, the “minimum viable use case” for using Git only requires learning a few relatively simple commands. Although Git is flexible and can support many different team workflows, there is a very simple pathway to learning the basics of Git. This is based around Git’s central concepts of the working directory, staging area, and committed changes.
The working directory is the set of code files and folders that currently exist on your filesystem. These are the files that you open in your code editor and make changes to. All version control systems have a working directory (or equivalent term), so this really isn’t unique to Git.
Once you’ve finished a particular coding task, like fixing a bug or adding a new feature, you can add your changed files to Git’s staging area (also called the staging index or cache) using the git add <file.ext> command. Think of this as a sort of purgatory for your code—it’s code that you are preparing to store permanently in Git once all your changes are placed there together.
The staging area is essentially a concept developed by Git. Other systems tend to skip this step, which in my opinion leaves out an important preparatory step that helps developers commit clean code.
The last part of the process is to commit the changes in the staging area to the Git repository. This is done using the command git commit -m “Commit message”. This takes all the changes that were added to the staging area and creates a new commit object, which is stored in your Git repository. This commit becomes the tip of the current branch, linked to the preceding commit in the chain, or parent commit.
The last three paragraphs essentially outline Git’s core functionality. The learning curve for these concepts is relatively shallow, which will keep onboarding new developers into Git’s ecosystem. Therefore, Git will continue to be an essential coding tool for new developers to learn.
Other Efficiencies in Git
In addition to the basic functionalities described in the previous section, Git has numerous other design principles and features that make it a more efficient tool than VCS competitors. These include lightweight branching and merging, a flexible reference model, a content-addressable database, and many more.
Before Git came along, existing VCS tools like CVS (Concurrent Versions System) made merging code a nightmare. With CVS, users often ended up with complex conflicting code changes that took a lot of effort to resolve manually. Git popularized the “merge easy and often” paradigm, where developers create new branches often, even for small features/fixes, and Git can usually handle merging the changes back into the main branch automatically.
This is great for developers because it minimizes the time and effort spent manually fixing merge conflicts.
Git also has an efficient reference model that is intuitive for developers without requiring them to get in the technical weeds. Git allows users to create names for their branches and to create tags that mark specific branch commits. Branch names and tags are part of a more general group of objects called references, or refs, that are pointers to underlying Git commits.
In addition, Git manages some refs, such as Git HEAD, to represent the tip of the current branch. These refs allow developers to easily understand which commits they are working with, without having to deal with complex Git jargon.
The last aspect we’ll touch on here is Git’s content-addressable object database. Git stores all of its data about your code in something called the object database. This is a hidden directory in your Git repository. When you track files with Git, add files to the staging area, and create commits, Git creates objects in the object database. These objects are named based on the content that they contain, which is why we call it “content-addressable.”
This allows Git to take advantage of numerous performance efficiencies and run various commands much faster than other tools.
Git Continues To Evolve
One final factor I will note is that Git’s code continues to evolve. Git has a very active open-source development community made up of a core set of developers surrounded by hundreds of other contributors.
Therefore, it is likely that even if other tools build out features that push the envelope of the version control industry, the expertise of Git’s developers will allow them to adapt and integrate similar functionalities into Git.
This gives Git a solid moat that protects the tool from the fast-changing technological competition of the 21st century.
Git’s Future
The factors described in this article form a strong argument for Git’s continued dominance in the future. Even if a new tool does prove to surpass Git from a technology or usability standpoint, it would take years for the majority of developers to switch away from Git to that new tool.
For comparative purposes, we can look at programming languages. Even very old programming languages like Fortran, C, and Perl are still in active use and development today despite the advent of newer alternatives such as Java, JavaScript, Python, Rust, Go, and more.
The key to staying power is that their communities live on. In my view, even if Git is surpassed by another tool, it will still hold a place in the software developer’s toolbox for decades to come.