Project Details

Merge Requests

merge requests

Under the item Merge Requests, which can be selected in the sidebar, you are presented with a list of all merge requests of the current project. The numbered badge right of the Merge Requests item tells you how many merge requests are currently listed as open for this project.

You can filter the list by merge request state using the buttons on the top right of the list header. Additionally you can sort the list using the sort menu.


The title of the merge request. Chosen by the author.


The actor currently responsible for advancing the state of the merge request. This can take the values Author, Reviewer, CI or Scans pending, Ready to merge. If one of those roles applies to you, the badge will appear red.

Learn how MergeBoard computes these value in Actors.


The overall state of the merge request, i.e. Open, Closed or Merged as well as various icons for information about discussions, reviewers, authors and other activities.


The merge request id, when the merge request was opened, in which project and by which author.


An indicator, how many of the change requests have been addressed.


The names of the source and target branch for this merge request. If multiple remotes are configured for this project, the name of the corresponding remote will also be shown next to the branch if the remote is not the default “origin” one.



The branches tab shows you all the branches of your repository. Here you can browse commits and view changes that have been made throughout the entire git history of the project. If you add multiple remotes to a project, the same branch name can appear multiple times (prefixed with the remote name).

Each entry in the list of branches shows you the branch name on top, below it the latest commit in that branch, its author and the time the commit was created. To the right you can find the status of the CI of the latest commit in that branch. A green check mark shows that the CI passed, a red cross that it failed. The CI status for the same commit can differ between different remotes.


By clicking on a branch’s name, you get to the list of all commits associated with that branch. Each commit is listed with its first line of the commit message, author and creation date on the left and its hash on the right. Clicking the Browse button allows you to view the entire code base at the state of the commit. Clicking the name of the commit displays all changes introduced by the commit. Learn more about diffs and how we present them at Diffs.



Here you can find a list of all remotes that you can use in your merge requests. Each remote is listed with its name and its default branch on the left and an indicator on the right, which tells you if the remote is currently syncing or synced and when the last synchronization happened.

You can

  • edit remotes by clicking their respective names.

  • trigger a synchronization of all remotes by clicking Fetch All.

  • add a new remote by clicking Add remote.

Each remote can store the CI state for a commit. Click on the remote to see a guide on how to setup CI Webhooks for GitLab and GitHub.



The members tab allows you to manage and verify the access permissions for this project.

You can

  • add a new user or group by typing their name in the User / Group field, assigning them a role and clicking Update.

  • change a user or group role by clicking their name in member list, changing their role in the field Role below and clicking Update.

User Roles

You can assign one of the following roles to a user or group. They are sorted by decreasing power in an descending way. More powerful roles can do everything the less powerful roles can.


Owns the project, i.e. can do anything with it.


Can do anything with the project, except deleting it. Can changes roles of other users.


Can add and edit merge requests.


Can review and approve merge requests.


Has read-only access to the project.

If a user is assigned to a project in multiple ways, e.g. directly and through a group, the permissions are merged. If the user is assigned to a project through a chain, e.g. the user is part of a group which is directly part of the project, each part of the chain can only reduce the permissions, but not extend it.

Depending on your configuration, it can be quite difficult to anticipate the final permissions for a user. To solve this issue you can verify the computed permissions for each user by selecting the Resulting Permissions tab on top of the member list.



Scanners are external tools that MergeBoard executes in order to find issues in your source code. Unlike a CI, scanners do not report a failure (unless their execution failed), but instead create review comments. These comments can be marked as False Positive so that they do not longer affect the mergeability of a merge request. Scanners are therefore a good alternatives to a CI if a tool tends to detect false positives.

Scanners are run for each revision of a merge request. It is also possible to trigger a manual rerun, for example, after changing the scanner settings.

Each of the scanners shown in the scanners list can be enabled by clicking the Enable button, if the scanner is installed. If not, contact you admin and have them install it for you. You can configure the scanners via the Configure button.

Issue Trackers


MergeBoard makes it easy to integrate a number of issue tracker or project management tools.

You can currently integrate Bugzilla, GitLab and GitHub issue trackers by clicking the Add button below the issue tracker list. Make sure to give it a distinctive name, as you can add multiple issue trackers of the same type. This can be very useful e.g. when you want to reference issues from your public and internal issue tracker.

Edit the issue tracker settings by clicking the Edit button. Here you can change basic settings like the url or api token for the issue tracker. Some issue trackers allow you to further customize their integration. For example, if adding an issue to a merge request should trigger a comment on the issue or if certain issue labels should be added or removed.

By clicking Delete you lose all references to the issue tracker. These cannot be restored.



In the project settings you can

  • change the name of the project,

  • change the icon of the project,

  • configure which conditions needs to be met before a merge request can be merged,

    • number of required approvals,

    • whether the CI needs to pass,

  • delete the project.