Merge Requests Concepts and Terms

As the name suggests, a merge request is a request to merge a branch into another. Before merging the branch, you may want your team members to review updates made to the branch and share their feedback. A merge request combines the review and merge processes into one easy collaborative process.

You can also link related issues and builds to the merge request that are automatically updated or triggered when you merge branches.

Here are the terms that this documentation uses to describe the merge request features and components:

Term	Description
Review branch	Branch to be reviewed and merged.
Target branch	Branch that the review branch will merge into.
Reviewer	Project user invited to review the changed files of the review branch.
Requester	Project user who created the merge request.
Subscriber	Project user who isn’t a reviewer, but is watching the merge request.
Default reviewer	Project user who’s automatically added as a reviewer if a branch is selected as the review branch. Only a project owner can create default reviewers of a branch.
Approved	Reviewer's feedback with no objection to the changes made to the source code in the review branch.
Rejected	Reviewer's feedback with objections to changes made to the source code in the review branch and a recommendation not to merge the review branch into the target branch.
General comment	A comment in the Conversations tab of the merge request.
Inline comment	A comment added to a line of a file under review.
Pending (or unpublished) comment	An inline comment that you didn’t publish when you added it.

To understand the workflow of a merge request, let's consider you're a software developer assigned a new feature to implement. These steps summarize the action you’d perform to set up a merge request and merge branches:

1. Create a branch from a stable branch (say main) of the source code Git repository. You'd add or update the files of the new branch to implement the new feature.

   You can do this in the cloned Git repository on your computer or on the VB Studio Git page.

2. On your computer, pull the latest content from the project’s Git repository, checkout the new branch, update the required files, and commit and push the checked out branch to the project’s Git repository.

3. If required, create a build job to generate artifacts from the new branch to verify the stability of the application.

4. Create a merge request with the new branch as the review branch and the stable branch as the target branch.

5. Add your manager and other team members as reviewers.

6. To resolve the feature related issues when you close the merge request, link the issues to the merge request.

7. Depending on the review feedback, you may need to update some files and check the stability of the branch. To trigger a build of the job automatically when you update the files of the review branch, link the job to the merge request.

8. Again, based on the feedback and build status of the linked jobs, you may want to merge the branch with the stable branch or abandon it. If you merge the branches, the linked issues are automatically resolved.

If you're invited to a merge request, you can add comments to the updated files, and share your feedback whether you’ve any objection to merge branches:

1. Open the merge request.

2. Check the commits made to the review branch and compare the changed files.

3. Add general or inline comments, if necessary.

4. Submit your feedback as Approved if you find the code updates acceptable, or Rejected if you have objections.

If you're a project member but aren’t invited to a merge request, you can add comments but you can't share your feedback.

It isn’t necessary to add reviewers to a merge request. If you're sure that the changes made to the review branch don’t require a review, you can merge both branches without a review. If you're comfortable using Git, you can merge branches from a Git client without creating a merge request.