Should You Use a Git Alternative?

Git logo

Git is incredibly popular and supported almost everywhere. Since this is practically the default version control system, the question arises: what are your alternatives? Is it worth considering them and how are they different?

Note that this article presents alternatives to git as source control software. If you’re just looking for alternatives to a hosted service like Github, you can read our guide to hosted Git solutions instead of.

The disadvantages of Git

To better understand the limits of Git, we must first start with what it does well.

Git uses a distributed source control model; each user’s local repository is not really connected to any central server. This user can log out, make a bunch of changes, and no one else will see these changes until they are pushed to the remote. It works extremely well for open source software development; Git is much faster for most actions, because individual users can all clone a repository and make their own small changes without having to worry about what others are doing.

These modifications can be incorporated into the master repository using extraction requests (the user making the modification requests so that the master repository obtains the validations of their private version of the repository) and updates transmitted by authenticated users, provided that all merge conflicts are properly resolved.

This model makes a lot of sense for this distributed development environment, but the problem with Git arises when you try to adapt it for use in an enterprise environment, where you will often have a lot of people working on the same bits of code , and appropriate coordination is key.

Don’t get me wrong here, it’s still fantastic, especially when paired with external problem tracking software and CI / CD pipelines, something like services like GitLab and BitBucket do pretty well. But Git wasn’t exactly designed to be an enterprise source control, where you’re almost always going to have a central server acting as your master repository. It requires very appropriate use (and often external tools) to be effective for agile teams pushing many code changes.

With Git, each client stores a full copy of the project change log. Each time you commit to Git, it stores the changes made locally on your system. It makes working with Git very fast, because you only need to query a hard drive and not a central server. It also makes it much easier for you to work offline. But with large projects with a long history of change, this can also lead to .git file occupying an unreasonable space.

Also, if you have multiple projects, you probably don’t want the source code of everything to be visible to each developer. In Git, this problem is usually resolved by having separate repositories for each project, which works quite well, but is not ideal if you need to integrate them together into a coherent room. With centralized version control, you can only give access to specific folders.

So while Git is probably not the false choices for your business, especially if implemented properly, there are other source control options designed specifically for business workflows, and it may be worth looking at the competition.

RELATED: How to configure a personal Gitlab server

The main alternative: centralized version control

The most common difference between Git and the alternatives is the breakdown of decentralized version control in favor of an authoritative central server. Apache Subversion and Team Foundation version control are the main version control systems that follow this format.

For comparison, in a DVC system, each user has a local repository in which he validates his own modifications. When they are ready to send updates to the master server, other users may have different versions of the same file you are working on. This is known as a merge conflict, and it is a very common (although easily resolved) problem with Git.

decentralized version control

In centralized version control (CVC) like Apache Subversion, there is a single server repository and many clients are directly connected to it. If you make a change to a file, that file is updated on other users’ computers each time it is updated. The validations are carried out directly on the master server.

To avoid merge conflicts, most HVAC systems use locks. If user A wants to work on a file and doesn’t want someone else to take care of it, they can lock the file until it’s done, preventing other users from doing the same. It’s not obligatory in Subversion, and merge conflicts can still occur, but they’re less of an accident.

centralized version control

The problem is mainly mitigated by branching and local copies, which allow multiple users to work on their own versions for long periods of time before merging the changes.

Another great feature of centralized version control is authorization management; rather than giving access to the entire repository, CVC facilitates the access section to specific files. Team Foundation Version Control works the same way as Subversion, allowing granular delegation of permissions down to the file level.

All of these features make centralized version control a viable alternative to DVC. After all, Google hosts all of its code in a massive and centralized system, much larger than any distributed system could handle. Granted, the Windows code base is a 300 GB Git repository, but it does use Git Virtual File System plugin, which allows users to download only the files they need, and nothing more.

One downside to Subversion is that it often has a lot of copies and downloads to make, which can make it a lot slower than the local Git-only model.

RELATED: The best alternatives to Github

Other alternatives

Although we have focused on centralized version control systems that can replace Git, there are other distributed version control systems that you can use, including Mercurial.

Mercurial is a little easier to use than Git, and they’re both pretty much the same in performance, but overall, they’re very similar. Really, there aren’t a lot of reasons to choose Mercurial over Git, aside from personal preferences, which probably shouldn’t dictate corporate decisions.

Mercurial was an option in BitBucket, but they recently dropped support, the main reason being that Git is right way more popular and widely supported. It is practically the default version control system, and unless an alternative radically changes the model (like CVC), it is not worth considering.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.