Introduction

In computer software engineering, revision control is any kind of practice that tracks and provides control over changes to source code. This is one of the things that developers need most. Because in any software project under development, there will be a lot of changes. There are numerous advantages to the continuous tracking of these changes in the project. Although these advantages are seen more clearly in teams with a high number of software developers, they also provide numerous advantages for individual works. If we want to summarize all the advantages in one sentence, it ensures that the team is always in harmony without losing the changes made to the files you are working on.

As the number of software development projects grew, software developers also needed to develop version control applications to avoid problems like code loss. Firstly, local-based applications, SCSS(Source Code Control System) and RCS(Revision Control System) etc., that emerged in the early 1970s. Then they evolved into a client-server applications, Panvalet, Software Change Manager etc., towards the end of the 1970s. The number of alternatives was also increasing rapidly in those days. But the biggest development that made the main difference in this matter was the transition to distributed technology in the early 2000s. This technology, which allows the developer to work quite quickly without the need for any network, became very popular. The most known and widespread member of the architecture, especially preferred by people developing open source projects, is Git. Git, which I can say that has almost changed our lives, has also created a huge ecosystem around it.

git

Let’s return to today’s topic after the theoretical knowledge in the introduction phase. We mentioned that Git created a great ecosystem. The biggest members of this ecosystem are the tools that provide hosting and managing the code sets, we call them as Repository in Git, for free. GitHub, described as the main one of these tools, has almost become the home of open-source developers. But for software developers who develops applications in corporate companies, on-premise solutions are required, where they can run on their own servers in some cases. Developers who are aware of this need have also worked on this issue and offered solutions with their and other developers needs. These solutions are also divided into 2 as open-source solutions and licensed solutions.

In this article, we will be examining TFS, GitLab and Gerrit among these open source and licensed products. We will have information about the usage, operating logic and capabilities of these products developed in line with different needs. Finally, we will interpret the differences between them.

TFS

Definition:

TFS is a Team Foundation Server and it’s a mixture of Version Control System (VCS), an issue tracker (like Jira) and also a combination of application lifecycle management tool. TFS has been working on its own version control system, also it supports Git for a while. In this way, project management, bug tracking and version management meet under a single application framework. TFS, which Microsof has been working on for many years and constantly announcing its new versions, is sold for a fee determined according to various features. We can call it as all-in-one solution for

Mechanism:

When you have multiple developers working together, and you need to release stable versions, and you would like to keep development going when releasing. It is the foundation for moving to a Continuous Deployment scenario. It is also an excellent way of making sure the “official” code is following at least some of your best practices guidelines. Using Pull Requests is built in to TFS.

You can easily setup your continues integration process with built-in tool.

Pull Request

Pull requests is a mechanism where you explicitly ask the server to merge your changes (commits) into a target branch. You can then set up rules for conditions for merging, and also a set of automatic steps that can be taken. A pull requests is also the item on which you can ask for a code review. This can also be automated.

So a pull requests server multiple purposes. It keeps the official code more clean, it opens up for code reviews, it ensures your stuff builds green before it goes into the official code base.

Gerrit

Definition:

Gerrit is a web-based tool that is used for code review. Its main features are the side-by-side difference viewing and inline commenting, which makes code reviews a quick and simple task. It is used together with the Git version control system. Gerrit allows authorized contributors to merge Changes to the Git repository, after reviews are done. Contributors can get their code reviewed with little effort, and get their changes quickly through the system.

Mechanism:

Gerrit usage has two stages: First, the contributor uploads changes to Gerrit with Git, and second, peers use the web browser to make reviews. The review process includes the following steps:

• Review Changes
• Publish comments
• Approve or abandon Changes

Git provides a mechanism to continually update a commit until it’s perfect: use git commit --amend to remake (re-record) a code change. After you update a commit in this way, your branch then points to the new commit. However, the older (imperfect) revision is not lost. It can be found via the git reflog.

Gerrit identifies a conceptual change with a footer in the commit message. Each commit message footer contains a Change-Id message hook, which uniquely identifies a change across all its drafts. For example:

`Change-Id: I9e29f5469142cc7fce9e90b0b09f5d2186ff0990`

Thus, if the Change-Id remains the same as commits are amended, Gerrit detects that each new version refers to the same conceptual change. The Gerrit web interface groups versions so that reviewers can see how your change evolves during the code review.

One of the main difference of Gerrit is, review process starts with developer’s commit. Only reviewed and approved commits can take place at origin. Also, although TFS and GitLab offer solutions for the whole DevOps process; Gerrit only serves a Git with code review.

GitLab

Definition:

GitLab is a web-based DevOps lifecycle tool that provides a Git-repository manager providing wiki, issue-tracking and CI/CD pipeline features, using an open-source license, developed by GitLab Inc.

The code was originally written in Ruby, with some parts later rewritten in Go, initially as a source code management solution to collaborate with his team on software development. It later evolved to an integrated solution covering the software development life cycle, and then to the whole DevOps life cycle. The current technology stack includes Go, Ruby on Rails and Vue.js.

You can use GitLab as an online Git repository. like Github. Furthermore, you can install it to your server and use as on-premise solution. In addition if you use GitLab CI Runner with installing it to your server, you can complete whole continues integration lifecycle easily.

Mechanism:

GitLab’s flow works with Merge Requests. The sound of Merge Request comes familiar, I know. Merge Request and Pull Request are same feature of different products which provides to manage git repositories. GitLab explains this subject with “Merge or pull requests are created in a git management application and ask an assigned person to merge two branches. Tools such as GitHub and Bitbucket choose the name pull request since the first manual action would be to pull the feature branch. Tools such as GitLab and Gitorious choose the name merge request since that is the final action that is requested of the assignee. In this article we’ll refer to them as merge requests.” sentences.

Which Will You Choose?

When deciding which one to choose, you should definitely consider your needs. Because your needs will allow you to decide whether the tool is useful or not.

For example, if you want the reviews must be on each commit instead of merge request, the tool you need to use will be Gerrit. But the configuration and learning curve of Gerrit can make your job a little difficult because Git commands that you are not familiar with are included.

If review is more suitable for you during merge and you need a lot of time during preparing release and want to manage them easily from only one tool, you can use GitLab. However, you should not forget that it is a structure that works entirely on the cloud and also the policies of the company you are working with. For example, banks in Turkey, they do not hold any data on cloud structure, including codes. In this case, GitLab’s on-premise solution can be preferred.

TFS is Microsoft’s licensed product so it’s not suitable for small and growing teams. Because you need to pay for every license. But if you work for corporate company that has Microsoft licenses, TFS should be nice selection for managing whole project. With TFS, you can use agile boards, Git repos and easy to use DevOps tool.

To sum up, you should decide your needs. There is no great solution that applies to all companies. Everyone should choose the best according to their needs.

Author: Efecan Tekin

Tags