Pull Request vs. Merge Request. What’s the Difference?

In the world of distributed version control systems, Git is undoubtedly the most popular one. Every repository manager, administrator, or developer uses pull and merge commands on a daily basis, but what do they really do, and when should we use them? What are the differences between these requests and the most popular Git-based systems? And finally, why should we know the git fetch command and the mechanisms behind each of our pulls.

This is another in a series of articles in which we explore concepts such as local repository, local branch, git push, git clone merge request, git pr request, sourcetree pull request, and more.

Fetch request?

The git pull and git merge commands appear in the title of this article, but to present them well, fetch should also be discussed, and we will explain here why. Because to understand the request itself and the difference between git pull and merge, it’s best to present it in terms of the mechanisms behind git fetch and git merge. This approach of the case may seem a bit “twisted” but stay here with me.

Mechanisms behind git merge and git fetch

The first of these mechanisms is git fetch, which is downloading the source tree, but that’s where it ends. This means that we will have our version and the version currently in the source tree. Thanks to this, we are able, for example, to check very carefully what changes are between the local and the source code.

Contrary to appearances, this is a very important issue. For security reasons, we should always check if our changes are correct and in the place where they are definitely intended.

On the other side of the approach to deploying your changes is the git pull command. In a way, this command is nothing more than a combination of git pull and merge that is performed in the background. This means that when we execute the git pull command, we first get the source from a remote or specified tree, which means that git fetch is currently being performed. Then, after checking that the local tree exists, they are merged.

Pull request & merge request – where lies the problem?

On the version control systems market, we have such powerhouses as GitHub, Bitbucket, or GitLab. The mentioned projects are outstanding and recommended systems based on Git, but they have some significant differences between them. For example, GitHub is and continues to develop as a version control system. Still, GitLab, on the other hand, also places great emphasis on developing its product as a platform for teams. This means that in addition to being a version control system, it provides its users with planning, scanning, monitoring, etc., tools.

Git improved your software development process? Do the next step and secure your code with the first professional GitHub, Bitbucket, and GitLab backup.

So what’s all the fuss about?

We have already discussed the operation behind the pull request and merge request, and since we already know this, we should move into the world of Git-based version control systems and be ready for whatever we encounter on our way?

Of course, everything is simple as long as we operate within Git itself. Problems come with the use of different VCS that use Git for their operation. A perfect example is GitHub and GitLab. Using the provided GitLab and GitHub documentation, we find out that… Exactly, something is wrong here. The two companies have different approaches to combining changes in the tree. A GitLab merge request is similar to a GitHub pull request. It is because of such differences that we should always have an up-to-date backup of our repositories. After all, we cannot indeed assume that, for example, an employee who has worked with Git so far only wanted to compare the changes, but missed that we use GitLab at the company.

Git pull or git merge – the summary

We can present the git pull command as a combination of git fetch and git merge. It means that the source code will be downloaded, and if the reference of this code has been indicated, the changes will be combined. Git merge, on the other hand, is only the second part, i.e., combining changes into one consistent tree. At this point, representatives of the Git-based version control systems market enter the scene. For example, a GitLab merge request will work just like a GitHub pull request. For this reason, it is always worth familiarizing yourself with the official documentation or at least seeking the help of the proverbial commands that we intend to use. However, the most critical part is a good and dependable git backup. And GitProtect – #1 professional git repository and metadata backup for GitHub, Bitbucket, and GitLab – will take care of that. Thanks to the intuitive and no-maintenance needed approach to the backup, users always have a safe and ready-to-restore copy.