What Version Control System is the best for you? Migrate to Git?

Since the arrival of cloud computing, the frequency of software updates has increased significantly. Therefore, choosing the right version control system (VCS) is crucial for ensuring the productivity of your team and the long-term success of your project. Over the last 20 years, Git has become the standard VCS. If we look at the Stack Overflow Developer Survey from 2022, almost 94% of respondents said that they use Git as their VCS, while approximately 5% use Subversion and 1% use Mercurial. While the strong preference for Git is evident, there are still many organizations that use VCS other than Git.

If you are one of them and wonder whether you should migrate to Git or not, you have come to the right place. In this article, we will share some insights and a real-world success story from one of our clients. We hope these will help you decide if a Git migration is the right step for your organization.

“Migrating from SVN to Git enabled our teams to fully embrace modern software development practices. It wasn’t just a tooling change; it was a shift in how we collaborate, automate, and deliver quality software. Git connected us to a broader ecosystem that accelerated our agility and innovation.”
Leonardo Quevedo, GeoSoftware CTO

Version Control Systems

Before we dive into Git and its features, it’s imperative that we understand the basic concepts that revolve around version control systems.

A VCS records changes made to a file or a set of files and provides the ability to recall specific versions later. As you already probably know, there are multiple reasons why we would like to have that. First of all, a VCS allows us to track what changes were made, who made them, when they were made, and why they were made; essentially, it provides traceability. Moreover, a VCS gives us the ability to revert changes if they are incorrect or no longer needed. This makes it difficult to break the project beyond repair, since you can always go back to a previous version. That’s the magic of a VCS: everything is recorded, nothing is lost.

There are three major types of version control systems:

• Local VCS: As the name implies, this type of VCS works only locally and consists of a simple database that stores the changes made to the files. To collaborate, the developers need to have access to the same machine. This was the primary drawback of local VCSs, and the reason why centralized VCSs were developed. An example of a local VCS is the Revision Control System (RCS), which was released back in 1982.
• Centralized VCS: On a centralized VCS, there is a main server that stores the versions of the files. The developers can check out the files from this server and make the changes on their machines. After the work is done, they push the changes back to the main server. Subversion (SVN) belongs to this category.
• Distributed VCS: On a distributed VCS, each developer has a local copy of the complete repository on their machine. Considering this aspect, in case of an outage, (1) each local copy can be used as a backup and (2) the work of the developers will not be impacted. Git and Mercurial belong in this category.

Let’s explore Git

Now that we have a basic understanding of VCSs, it’s time to dive into Git. As we have mentioned before, Git is the most popular distributed VCS. But why? In order to understand that, we need to look over the most notable features of Git:

• Open Source: Git is released under the GNU GPLv2, which means that you are allowed to use, modify, and redistribute the software without being required to pay a fee for doing so. There is only one drawback here. If you want to release a modified version of Git, you will have to use the same license.
• Fully distributed: As we mentioned before, when using Git, all developers have their own local copy of the repository. This allows Git to provide excellent redundancy and resilience, since if something happens to the central remote repository, the codebase can still be retrieved from one of the available copies.
• Speed: Git was designed for speed and efficiency. Since it is fully distributed, most actions are performed locally, giving it a significant speed advantage over centralized VCSs, where you need to retrieve information from a central server. Just to give an example, when compared to Subversion, Git is one or two orders of magnitude faster.
• Non-linear development: Git workflow is centered around the concepts of branching and merging. Each new feature that your team wants to add will begin as a separate branch. Once the development is complete, the branch is merged into the main branch. This way, Git encourages working on multiple features simultaneously.
• Data integrity: Every object stored in Git is hashed using the SHA-1 (and more recently, SHA-256) hashing algorithm. Considering this aspect, any corruption of the stored data will be easily detected. Additionally, Git history is immutable, since any modification to the commit metadata or the files included in the commit will alter the hash.

As you can see, Git has multiple features that make it the go-to solution when choosing a VCS. However, before making any decision, it would be beneficial to discuss the potential impact Git might have on your team.

Is Git Right for You?

As every organization is different, the answer to this question is not a straightforward yes or no that applies universally. Depending on how well developed your organization’s workflows are, a Git migration might be more or less beneficial. Also, the potential challenges and drawbacks that might arise during a migration should not be overlooked. We strongly believe that it is better to have a clear overview and be well-prepared beforehand than to regret it later.

With this in mind, we will analyze further how Git might improve your workflow. We will explore the potential risks associated with migration and discuss strategies for overcoming them.

Git’s Potential Impact

1. It will facilitate parallel development – As we have seen, Git is focused on non-linear development. Starting to work on a new feature is a very straightforward process: you just create a new branch and begin your work. Developers can create as many branches as needed, as branches are essentially pointers to specific commits and don’t consume additional disk space. Therefore, the developers will start to work on multiple features simultaneously, without conflicting with each other.
2. It will encourage experimentation – Because branches can exist locally, are lightweight in terms of disk space, and are transitory, developers are more likely to experiment with new feature ideas in their local environments.
3. It will facilitate the implementation of CI/CD – Because Git is the most popular VCS out there, almost all automation tools are directly integrated with it. This makes it easier to implement CI/CD pipelines in order to automate your build processes. You can even go beyond and automate your deployments for testing purposes. This will provide your team with fast feedback, accelerating time-to-market.
4. It will enhance the code review process – Multiple Git hosting services like GitHub, GitLab, and BitBucket provide the ability to review the changes from a merge request directly from their platform. Moreover, other team members can leave comments in which they can reference snippets of code or even add images. The review process can also be enforced, ensuring that a set of changes will not be merged until a maintainer has reviewed them.
5. It will enable you to leverage community expertise – At the moment of writing this article, there are over 150.000 Git-related questions on Stack Overflow. For comparison, Subversion has around 26.000, and Mercurial has about 8.000. Given Git’s widespread adoption, you are likely to find solutions to the most common issues. If your question has not been asked yet, you can ask it yourself, and there’s a good chance someone from the Git community will provide an answer.

Potential Challenges and Strategies to Overcome Them

1. The migration process might be pretty complex – While there are tools available to assist with a Git migration (such as svn2git and fast-export), the process can still be quite challenging. This is especially true if your organization has multiple large repositories with complex histories. In my experience, depending on the factors mentioned earlier, a Git migration can take anywhere from a single day to several weeks.
2. You may want to use a Git hosting service – If you’re going to migrate to Git, most likely you would also like to use a Git hosting service, such as GitHub, GitLab, or BitBucket. Since there are multiple options available, it is important to review them and choose the one that will suit your organization best. You also may want to think about where you want to have the service hosted. Do you need it to be self-hosted, or would a SaaS solution be better?
3. Existing automations may need to be refactored – A migration to Git might cause existing automations implemented in your project to no longer function properly. In this case, it is essential to be aware of what might break and to take the necessary measures to minimize the impact. Ultimately, the complexity surrounding Git and the processes tied to it will dictate the preparation time for the migration process.
4. You may need additional infrastructure – If you want to go with a self-hosted approach, you should think about where you want to host the Git hosting service. Also, if you want to implement CI/CD using self-hosted runners, this point is all the more critical.
5. There will be a learning curve – If your team is not familiar with Git, they will have to get used to a new set of concepts and commands. To facilitate this process, you can arrange Git training sessions for your team. Also, if there are some team members with prior Git experience, they should be encouraged to help their colleagues.
6. There may be resistance to change – If your team has been working with another VCS for a long time, they might be reluctant to migrate to Git. In order to have a high adoption rate, it is vital to demonstrate specific ways in which your team may benefit from using Git. In other words, your team should know what particular issues this migration will solve and how Git will improve their work.

From SVN to Git and Beyond – GeoSoftware’s Journey

GeoSoftware is a leading provider of advanced geoscience software solutions focused on seismic interpretation, geophysical analysis, petrophysical modeling, and reservoir characterization. A few years ago, GeoSoftware approached Yonder with several challenges:

• GeoSoftware had multiple SVN repositories that had grown significantly in size, reaching the point where a single clone of a large project was taking up to several hours.
• GeoSoftware repositories had their histories filled with binary files, many of which were no longer needed and could be removed to reduce the size of their repositories.
• GeoSoftware developers wanted a more streamlined process for creating new branches and collaborating on new features, which was a key reason why they considered migrating to Git.
• GeoSoftware sought to introduce quality gates and implement automated code reviews to better manage and reduce technical debt.
• GeoSoftware wanted to reduce the time required to build their products so that they could be as responsive as possible to customer and market demands.

After further discussions and several discovery sessions, we determined that a Git migration would be beneficial, but we also uncovered additional requirements and complexities that had to be addressed:

• We had to decide which version control platform to use. Should we recommend a SaaS solution or a private cloud approach? After considering all available solutions, we advised GeoSoftware to proceed with a self-hosted GitLab in a private cloud.
• We needed to assist GeoSoftware in migrating their repositories to Git and cleaning up the associated histories to remove unnecessary binary files.
• We had to provision extra infrastructure for the self-hosted GitLab, GitLab runners, the object storage system, and all of the other necessary components.
• The build process was closely integrated with SVN, so we needed to refactor parts of it to ensure compatibility with Git. We also had to add the build process of each product to a CI/CD pipeline.
• We had to ensure that the GeoSoftware development team would have a smooth transition, as many of them had no prior experience with Git. To support them, we prepared comprehensive documentation and organized online sessions to explain and demonstrate the new workflow.

As you can see, although the migration process may appear straightforward at first, there are several important factors to consider.

To illustrate the impact of the migration, let’s review the development process before the migration and how it looks now.

Before the migration

• Code reviews were conducted by sharing patches via email, resulting in low adoption and inconsistent quality control.
• SVN lacked integration with modern CI/CD pipelines, limiting our ability to automate testing and analysis.
• Feature branching was cumbersome, making it difficult to break down work into manageable units.

After the migration

• Every merge request now triggers a structured code review within GitLab, increasing review participation and code quality within GeoSoftware product development, resulting in more stable, higher-quality software releases to their clients.
• Git’s integration with CI/CD tooling enabled automated static code analysis and vulnerability scanning; critical capabilities that not only enhance GeoSoftware’s internal quality assurance but also address clients’ increasing expectations for secure, resilient software solutions.
• Feature branching is now seamless, allowing teams to break epics into well-sized stories and improve delivery cadence, ensuring that GeoSoftware clients receive timely software updates and enhancements.
• There has been measurable value in terms of efficiency, process automation, quality control, and actionable analytics, all of which benefit GeoSoftware’s client base.

Conclusion on migrating to Git

Migrating to Git can offer significant benefits to your organization, particularly when it comes to flexibility, faster development, experimentation, and a vast ecosystem of tools and integrations. However, as we have seen together, the migration process also presents various challenges, such as the initial setup overhead, potential disruptions to existing workflows, and the need to retrain teams and support their adaptation to the new tools. In conclusion, before making a decision, it is critical to assess very carefully how a migration would impact your organization.

Article by
Emilian Rosca
DevOps Engineer