What is GitLab and How Do Pull Requests Work in GitLab

Whether we’re working solo or as part of a team, version control systems like Git are essential for managing code efficiently. GitLab stands out as one of the top platforms built around Git, offering a comprehensive suite of tools that supports every stage of the DevOps lifecycle. Unlike other platforms that depend on third-party integrations, GitLab brings everything together - source code management, continuous integration and continuous delivery/deployment (CI/CD), project planning, security, and more - into a single, cohesive application.

In this article, we’ll explore what GitLab is and dive deep into how pull requests - referred to in GitLab as merge requests - help streamline collaboration and code quality. We’ll walk through how pull requests work, how to create them, common pitfalls to avoid, and best practices to follow. Whether we’re just getting started with GitLab or looking to improve our development workflow, understanding pull requests is a key step toward more effective and efficient collaboration.

What is GitLab?

GitLab is an open-source platform built to support the entire software development lifecycle. At its core, GitLab provides Git repository hosting, but it goes far beyond that. By integrating tools for code collaboration, issue tracking, automation, and deployment, GitLab empowers teams to work more efficiently in a unified environment.

Key features of GitLab

The several key features of GitLab include:

• Source code management: Provides Git repository hosting with tools for code browsing, version control, and branching strategies.
• Pull/merge requests: Enables peers to review the changes before they merge them into the main branch.
• CI/CD: Automates testing and deployment processes.
• Issue tracking: Allows teams to track bugs, feature requests, and project milestones.
• Security and compliance: Integrates static and dynamic code analysis, container scanning, and more.

Next, let’s have an overview of what a pull request is in GitLab.

What is a pull request in GitLab?

In GitLab, a pull/merge request is a way to propose changes we’ve made in a feature branch to be merged into a target branch, often the main branch or the develop branch. It acts as a structured conversation around a set of code changes, allowing developers to review each other’s work, discuss improvements, and ensure everything meets project standards before merging.

Purpose of a pull request

A pull request serves multiple purposes:

• Code review: It allows team members to review code before it’s merged, helping to catch bugs, enforce coding standards, and share knowledge.
• Collaboration: Developers can comment on specific lines, suggest improvements, and engage in discussions directly within the context of the code.
• Documentation: Each pull request records what was changed, why, and who changed it. This creates a valuable history for future reference.
• Testing and validation: GitLab’s CI/CD pipelines can automatically run tests, linting, and deployment scripts when a pull request is created or modified to ensure changes meet quality standards before merging.

We’ve learned what a pull request is and how it helps, but do we know the different types of pull request workflows we can use?

Let’s explore this mystery in the next section.

Types of pull request workflows

GitLab supports various pull request workflows to accommodate different team sizes, project complexities, and collaboration styles. Choosing the right workflow can improve team productivity, reduce merge conflicts, and help maintain a clean and organized codebase. Let’s take a closer look at these workflows one by one.

Feature branch workflow

This is one of the most popular workflows in both small and large teams. In this approach, each new feature, bug fix, or enhancement is developed in its own dedicated branch - usually named something like feature/user-auth or bugfix/login-error.

How it works:

• Developers branch off from the main branch (e.g., main or develop).
• After completing the changes, they push the feature branch to the repository and raise a pull request targeting the main branch.
• The pull request undergoes review and testing before being merged.

Forking workflow

Commonly used in open-source projects, the forking workflow allows contributors to make changes without having write access to the main repository.

How it works:

• A contributor forks or makes a personal copy of the original repository.
• They clone their fork to the local machine, make changes in a new branch, and push those changes back to their fork.
• They then create a pull request from their fork’s branch into the original repository.

Git flow workflow

Git flow is a more structured and formalized branching model suitable for projects with scheduled releases and multiple environments (e.g., development, staging, production).

How it works:

• There are dedicated branches for each development stage: develop, release, hotfix, and main.
• Features are branched from develop and merged back into it through pull requests.
• Release branches are created for staging/testing and eventually merged into both main and develop.
• Hotfix branches are used to patch production issues quickly and are merged into main and develop.

Trunk-based development

In this minimalist workflow, all developers commit to a single main branch (sometimes called trunk) with small, frequent changes. Feature flags are often used to hide incomplete functionality.

How it works:

• Developers create short-lived branches or even work directly on the main branch.
• Pull requests are created frequently, sometimes multiple times a day.
• CI/CD ensures rapid testing and deployment.

Each of these workflows has its own strengths, and the best choice depends on our project’s needs, team structure, and release process. Teams often adapt or combine elements of multiple workflows to suit their specific context.

We’re now aware of GitLab, pull requests, and the different types of pull request workflows. However, we still don’t know how to create a pull request in GitLab. So, let’s discuss that next.

How to make a pull request in GitLab

Here’s a step-by-step guide for creating a pull request in GitLab:

Step 1: Go to the repository where you want to open the pull request. If you want to follow along with the guide, navigate to the demo repository. Then, click on the Fork button at the top-right corner of the screen to fork the repository.

Step 2.1: The Fork project page appears. This page allows us to configure the fork that we want to create. Here:

• Under Project name, provide the name of the fork (demo in this case).
• In the dropdown that comes between Project URL and Project slug, choose the group under which you want to create the fork.
• Under Project slug, insert the slug for the fork (demo in this case).
• Leave Project description blank.

To configure the remaining options, move on to the next step.

Step 2.2: Here are the configurations for the remaining options:

• Under Branches to include, choose All branches.
• Under Visibility level, choose Private.

Finally, click on Fork project to fork the demo repository with the specified details and settings.

Step 3: After forking, we’ll be redirected to the forked repository. In the repository page, click on the Code dropdown and copy the link provided under Clone with HTTPS.

Step 4: Open the terminal on your local machine and run this command:

git clone <link>

to clipboard
Copy to clipboard

Replace <link> with the link that you copied.

Running this command clones the forked repository to your local machine. After the operation is complete, a folder (repository) named demo will appear in the current directory.

Step 5.1: Navigate to the repository.

cd demo

to clipboard
Copy to clipboard

Step 5.2: Once you’re in the repository, run this command to create and switch to a new branch named test.

git switch -c test

to clipboard
Copy to clipboard

Step 5.3: Open the README.md file in Nano, a useful command-line text editor:

nano README.md

to clipboard
Copy to clipboard

Step 5.4: Make changes to the file by selecting the entire text and replacing it with this new one:

I’m learning how to create a pull request in GitLab!

to clipboard
Copy to clipboard

Once done, hit Ctrl+X to exit, Y to save the changes, and Enter to keep the file name as it is and return to the regular terminal mode.

Step 5.5: Add and commit the changes.

git add README.md
git commit -m "Modify README.md"

to clipboard
Copy to clipboard

The -m flag enables us to write an inline commit message, avoiding the hassle of launching the default text editor and writing the message in it.

Step 5.6: Push the changes to your fork.

git push origin test

to clipboard
Copy to clipboard

Here, origin refers to the forked repository. This setting is automatically set when we enter the cloned repository for the first time.

Step 6: Navigate to the forked repository. You will see a Create merge request button. Click on it to go to the pull/merge request creation page.

Step 7: On this page, insert the title and description as provided in the image, and leave the other options as they are.

Step 8: Click on ‘Create merge request’ to create a pull/merge request with the specified details and settings.

Congratulations, you’ve successfully created your first pull request in GitLab!

With that said, let’s look at some common errors that contributors face while creating pull requests in the next section.

Common errors while creating pull requests

While creating a pull request is generally straightforward, it’s not uncommon to run into issues - especially as projects grow in complexity. Understanding these common errors can help us prevent delays, streamline collaboration, and ensure smoother code integration. Let’s go through some of them individually.

Merge conflicts

Merge conflicts occur when the source and target branches have conflicting changes that GitLab can’t automatically resolve.

Why it happens:

• Multiple developers modify the same line of code in different branches.
• The base branch has progressed significantly since the feature branch was created.

How to fix it:

• Rebase or merge the latest changes from the target branch into the source branch.
• Resolve conflicts locally in a code editor or using Git.
• Push the updated branch to update the pull request.

Failing CI/CD pipelines

When automated tests or jobs defined in GitLab CI/CD fail, the pull request is often blocked from being merged.

Why it happens:

• Failing unit or integration tests
• Misconfigured .gitlab-ci.yml file
• Missing environment variables or dependencies

How to fix it:

• Check the pipeline logs directly in the GitLab UI.
• Debug the issue locally and rerun the pipeline if needed.
• If the failure is unrelated to the changes, coordinate with the team to fix it.

Unresolved discussions/comments

GitLab can be configured to prevent a merge until all code review discussions are resolved.

Why it happens:

• Reviewers leave comments requesting changes or clarification.
• Discussions are marked as unresolved even if addressed in code.

How to fix it:

• Respond to each comment and make any required changes.
• After the changes are approved, mark discussions as resolved.

Missing approvals

Projects with protected branches may require one or more approvals before a pull request can be merged.

Why it happens:

• The required number of approvals hasn’t been met.
• The pull request hasn’t been reviewed yet.

How to fix it:

• Assign the pull request to specific reviewers or add them as approvers.
• Politely nudge the team via comments or Slack for reviews.
• Check project settings to confirm approval rules.

Next, let’s go through some best practices that we can apply to create pull requests efficiently.

Best practices for creating pull requests

Applying these best practices will help us ensure smooth collaboration and fewer hiccups during the pull request review process:

• Keep it small: Break large features into smaller, manageable pull requests.
• Write clear descriptions: Explain what the change does and why it’s needed.
• Use draft pull requests: Mark the pull request as a draft if the changes are not ready for review yet.
• Tag reviewers: Request reviews from specific team members.
• Run tests locally: Ensure the changes pass the tests before pushing.
• Reference issues: Link related issues for better tracking (e.g., Closes #123).

Conclusion

In this tutorial, we explored GitLab and how pull requests play a critical role in modern software development workflows.

Creating pull requests is more than just a technical task - it’s a core part of effective communication and collaboration in a development team. By taking the time to write clear descriptions, follow structured workflows, and engage with reviewers constructively, we not only improve the quality of our code but also foster a healthier team culture.

If you want to learn more about Git branching and collaboration, check out the Learn Git: Branching and Collaboration course on Codecademy.

Frequently Asked Questions

1. GitLab vs GitHub: Which is better?

Both platforms offer robust Git repository hosting and collaboration tools. GitHub is a widely used platform in the open-source community and offers great integrations. GitLab, on the other hand, excels in providing an all-in-one DevOps solution with built-in CI/CD and security tools.

2. What Is the difference between pull and merge request in GitLab?

In terminology, GitHub uses ‘pull request’ while GitLab uses ‘merge request’. Functionally, they are the same - a method to propose, review, and merge code changes.

3. What is the difference between pull and push?

In Git, pull fetches and merges changes from a remote repository to your local machine, while push sends your local changes to the remote repository. Essentially, pull brings in changes, and push shares your changes.