Skip to main content

Merge Requests

Git Merge Requests (MRs) are integral to Therefore, it is necessary to have a profound understanding of "everything" merge requests, including creating, reviewing, and merging the code in the MR's feature branch into the main branch. Also, resolving merge conflicts is a relatively common part of merging feature branches into the main branch. For more information on this topic, check out Resolve Merge Conflicts.

Merge requests tips and tricks

Here are some notes on what you can do with merge requests in (in no particular order):

Suggesting changes to a merge request

Merge request suggestions are a vital part of MR. They reduce the feature branch development and merge cycle time. Historically, suggestions could be given and applied, but the commit message was always a default, resulting in the need to squash all the commits in the MR when merging with the main branch. To retain an accurate commit history, developers and contributors would either have to go back and reword the commit messages after applying the changes or manually apply the suggestions locally.

This method has the potential to waste a lot of time. Now you can write a custom commit message when applying a suggestion, following best practices for your organization.

custom-commit-message !!shadow!!


If a custom message is not specified, the suggestion is committed with a default commit message.

Notifying participants that a merge request is marked ready includes the functionality of sending a notification to participants of the merge request when marking a merge request as ready. Alerting merge request participants that your merge request is prepared for review helps shorten cycle time and ensures that outstanding merge requests are merged faster.

Requesting a follow-up review from a reviewer best practice recommends "two pairs of eyes on everything." This ensures "a manual check is completed before each pull request and code merge." For more information, see Pillar 5 on the #TrueDataOps website. This code review often generates feedback from the reviewer, resulting in the need for a re-review of the code.

You can request a re-review from your reviewer in the UI. This triggers a to-do item and email notification to alert your reviewer that you need a follow-up code review.

Marking changes as viewed in merge requests

Reviewing merge requests containing large numbers of files can be challenging. These reviews are often inefficient because you often end up reviewing work that has already been reviewed.

In, you can mark files as reviewed (see image below for details) to mark that the files have been reviewed, staying up to speed with what has already been reviewed and what still needs to be reviewed.

mark-as-viewed-1 !!shadow!!

Merge requests pipelines

A merge requests pipeline is triggered every time a merge request is created or updated in the merge request's source branch to ensure that the commit history to be merged into the target branch will not cause any issues. Thus, when a merge request is created, a pipeline is initiated to verify the status of the source branch's pipeline. This includes checking if the last pipeline on the source branch is successful, blocked, failed, or canceled.