Jump to content

GitLab/Workflows/Making a merge request

From mediawiki.org
UML diagram showing the trusted contributor GitLab workflow

Clone a repository from GitLab[edit]


Create a branch[edit]

Use the convention work/{{your username}}/{{topic}}:


Make your changes[edit]

Write some code and save your changes.

Stage and commit your changes[edit]

Let's say you've edited the README.md in blubber. You should be able to see this using git status:


Stage the file and commit:


You should now be able to see this commit in the log:


Fork the repository[edit]

UML diagram showing new volunteer GitLab workflow
If you have commit access, you can push your branches directly to origin without having to fork, and safely ignore this section.

If you don't have developer-level permissions on the project you'd like to contribute to, you'll first need to copy the repository to your own account. This is known as "forking". Visit the repository page, for example https://gitlab.wikimedia.org/repos/releng/blubber, and click "Fork" in the upper righthand corner.

Now, select your username in the namespace dropdown under "Project URL". You may see a number of options, depending on what other namespaces you have access to. Once that's done, click the "Fork project button".

Next, add a remote for your fork:


If you've done this successfully, it should show up in your remotes:


Push your commit to GitLab[edit]

If you have commit access, you can push directly to a branch on the origin with git push origin work/user/refactor-readme.

If you're using a fork, push instead to the remote you added above with git push fork work/user/refactor-readme.


Create a merge request on GitLab[edit]

You may notice that GitLab responded to the push with a link to create a new merge request from your branch. You can follow that link directly, or visit the GitLab instance, navigate to the branch list for the repository, and click the "Merge request" button in the listing.

A screenshot of a GitLab Community Edition listing of branches on a repository.
If your branch is in a fork under your user account, remember to look there instead of in the origin repository.

Provide an informative title and description for the merge request, and @-mention the users you'd like to see review your code. You should be able to use the full range of syntax in GitLab Markdown.

Merge options[edit]

In the "Merge options" section:

  • Check "Delete source branch when merge request is accepted" to avoid cluttering the repository with already-merged feature branches. (This is probably the default.)
  • In the general case, you should use "Squash commits when merge request is accepted". (This is probably the default.)
    • Omit this if you plan to submit a merge request containing multiple commits.
    • If the logical structure of your change dictates multiple commits, you may use interactive rebase to achieve the desired history and force push to your work branch before merge. This is an advanced workflow, but supported.
  • Check "Allow commits from members who can merge to the target branch", unless you have a specific reason to prevent others from making changes.

Draft / WIP merge requests[edit]

If you want to let reviewers know that your change is a work in progress and prevent accidental merges, you can use a draft merge request. Prefix your merge request title with Draft: . This will display a notice and disable "merge" button for reviewers.

Adding commits to a merge request[edit]

Making new commits[edit]

Typically, you'll just make a new commit on your work branch, as usual, and push to the correct remote:

git push origin work/user/refactor-readme


git push fork work/user/refactor-readme

The new commit makes it very easy for reviewers to see what changed since they last saw the merge request, and will be squashed into the other commits when the pull request is merged, assuming that the pull request is set up to squash commits on merge (as recommended above).

Force pushing to a branch[edit]

If, instead, you wish to rewrite the history of the branch, for example by altering an existing commit or rebasing your work on top of upstream changes, GitLab allows force-pushing to a branch that's associated with a merge request. With this approach it is still very easy for reviewers to see what changed since the last push to the merge request.


This is mainly suitable for merge requests which are not meant to be squashed on merge, typically because they contain two or more commits that should remain separate. In that case, you clean up the history locally and then force-push it to update the merge request.

Getting code review[edit]

Once you've submitted a merge request, someone will need to review it. In addition to @-mentioning appropriate users in your merge request description or comments, you can assign a single reviewer. Do this by clicking "Edit" next to "Reviewers" in the sidebar at the right side of the page when viewing a merge request.

You may also use "Assignee" to indicate ownership of the merge request, responsibility for merging, etc., as useful to your workflow.

Please see Code review for documentation on reviewing code.

Local repository migration[edit]

Update your remote[edit]

When we migrate from Gerrit to GitLab you will need to update your remote repository url locally:

Remote url update:

Rename "master" to "main"[edit]

As part of the migration to GitLab, we are changing the mainline branch from master to main.

To update your local checkout (after changing your remote):

Branch renaming:

This transition is documented on Phabricator on phab:T281593 (and phab:T254646).

Sources and further reading[edit]

There's a lot of quality documentation available for GitLab, although navigating it can be a bit tricky.