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

Last Updated on October 30, 2024

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 blog post, in a series of articles, where we explore different concepts as whether you’re working on a feature branch or integrating local changes into the master branch, understanding Git operations like pull, push, and merge requests is crucial.

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. Well, to understand the request of considering git merge vs git pull, 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. The approach and idea 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 branches, the local one and the source code, so to say, the master branch (main branch).

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.

💡 When you use the git merge command, a merge commit is created to represent the point in history where branches have been combined.

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.

Let’s get back to the topic

Well, after covering the background of the main topic, and the mechanisms behind pull requests and merge requests, let’s have a closer look at pull requests and merge requests…

What is a pull request?

Usually, developers make pull requests when they want to merge the changes they did inside their local branch with the master branch of their repository. Moreover, developers can also use pull requests to discuss the changes they made and leave their feedback. Such comments help teams catch bugs or other issues before they may become part of a master branch or the main codebase… those

How to create a pull request?

Well, imagine that you are working on a feature branch, let’s call it “feature-new-1” and you need to merge it with your main branch, “main-branch-1”. To create a pull request, you will need to follow the given consequence of actions:

1. You need to commit the changes you’ve done to the feature branch:

git add .
git commit -m "Implemented feature-new-1"

2. You should push the feature branch to the remote repo:

git push origin feature-new-1

3. Open your GitHub, Bitbucket, GitLab, or Azure DevOps, and create a new pull request. Here you should choose your feature branch and the master branch to want to merge into.
4. Create a title and description for the pull request you want to create, and submit it for review. This will allow other team members to review your changes and leave their feedback.
5. After your changes are reviewed and approved, you can finally merge your pull request into the master branch:

git push origin feature-new-1

What is a Merge Request?

Like a pull request, a merge request allows the team of developers to make changes in the master branch. Though, the merge request is basically for GitLab. This feature allows developer teams to discuss changes and helps to ensure that the newly proposed code is thoroughly checked before it becomes part of the master branch.

Understanding how merge requests work is important for maintaining code integrity and facilitating collaborative software development. To create a merge request:

1. You need to create a new branch from the default one:

git checkout -b feature-new-1

2. Then, you should commit your changes to the new branch you’ve created:

git add .
git commit - "Implemented feature-new-1"

3. After that, you will need to push the changes you’ve made to the remote repository:

git push origin feature-new-1

4. Open your GitLab and create a new merge request. Choose the branch you’ve newly created and the default branch to merge them.
5. Set up and configure merge request options, including approvals or automated tests.
6. When your developer team has reviewed and approved your changes, you can merge your merge request and the default branch:

git checkout default
git merge feature-new-1

Pull request vs merge request – definition differences

In 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 tools, etc.

So what’s all the fuss about?

Whether we speak about Git pull or Git merge, they both are aimed at helping developers create new features or find and dismiss bugs without changing the project’s main branches. In this case, developers can write and test their changes in code in their local branch and have no worries about destroying the entire project they or other developers work on.

We have already discussed the operation behind the pull and merge requests, 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, as the result you achieve with both those commands is the same – you merge a developer’s branch with the project’s master branch or main branch. Moreover, both these requests promote collaboration within your team, and gather changes from other branches of forks, and finally, merge those changes with the code you have.

Hovewer, note, you should remember that there is some difference between the request and the command. If a user wants to execute a Git pull command, he will need to initiate a pull request. On the other hand, if a user wants to run git merge, he will submit a Git merge 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 merge, which helps integrate new changes with the existing code and improve collaboration among team members. 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 your data protection. Thanks to the intuitive and no-maintenance needed approach to the backup, users always have a safe and ready-to-restore copy.

[FREE TRIAL] Make sure that you have compliant DevOps backup and recovery with a 14-day trial 🚀
[CUSTOM DEMO] Let’s talk about how backup & DR software for DevOps can help you mitigate the risks and secure your source code