Merge Requests

A Merge Request (MR) is a request to merge one branch into another.

Use merge requests to visualize and collaborate on proposed changes to source code

How to create a merge request?

Before creating a merge request, read through an introduction to Merge Requests to familiarize yourself with the concept, the terminology, and to learn what you can do with them.

Every merge request starts by creating a branch. You can either do it locally through the command line, via a Git CLI application, or through the GitLab UI.

  1. Create a branch and commit your changes

    CLI Example git checkout -b "feature_branch" // Create a local branch with checkout

    You can also create a branch from Web Application, it depends on your work style. If you are creating a branch from GitLab UI and developing it from your favorite IDE; these commands will help you out:

    git fetch
git checkout feature_branch

    After creating a branch you should add your changes and commit your changes with commit message. For example:

    git add src/* // Add every changed file located at /src path
git commit -m "Add Login Endpoint."

  2. Push your local branch to remote git push --set-upstream origin feature_branch // Push your local branch to remote Now you are ready to create your merge request.

  3. Create a Merge Request

When you start a new merge request, regardless of the method, you are taken to the New Merge Request page to fill it with information about the merge request.

Important Notes:
*Always create merge request to source branch(the branch where you created new branch from).
For example if you created a branch from 'dev',open your merge request to 'dev'. Not 'master' or any other branches.

When creating merge request follow these steps listed below

  • Assign the merge request to a colleague for review. Generally more than one assignees are better.

  • Set a milestone to track time-sensitive changes.

  • Add labels to help contextualize and filter your merge requests over time.

  • Attach a related issue.

  • Add merge request dependencies to restrict it to be merged only when other merge requests have been merged.

  • Set the merge request as a Draft to avoid accidental merges before it is ready. While doing that you can use title prefix: WIP:.Don’t forget to add description line when it will be ready.

  • Write a description for changes (It’s also helps reviewers for understanding what are they looking at.) While writing a merge request description be sure you are helping reviewer to what he/she is looking at. Otherwise you should okay with your colleagues closing your merge request without merging it.

    Description Example:

    ## What does this MR Do?
* Adds Session Endpoint Paths to API Path List
* Reconfigure Public, User and Techinician Role Available API Path Lists.
* Adds Login, Logout and ValidateSession Endpoints

Closes #25!(Session Implementation)
  • Once you have created the merge request, you can follow these subsections to finalize the work:

Merge Request Reviews

  • Pipeline should successfully done.
  • Check whether MR description is done.
  • Review code carefully (Check How to review section)
  • If you have any discussion point, comment each one as a different topic. (Check How to discuss section)
  • If all threads/requested changes are resolved, merge it(Always FastForward).

How to review?

  • Perform a Review in order to create multiple comments on a diff and publish them once you’re ready.
  • Perform inline code reviews.
  • Add code suggestions to change the content of merge requests directly into merge request threads, and easily apply them to the codebase directly from the UI.
  • If everything looks ok, please approve the code with a comment so that new any other reviewer can see your comment and close the MR if needed.

How to discuss?

  • Company public language is English. Be aware of that
  • Always try to be constructive
  • Explain every details of problem to transfer your idea/concerns clearly