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.
Create a branch and commit your changes
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."
Push your local branch to remote
git push --set-upstream origin feature_branch // Push your local branch to remoteNow you are ready to create your merge request.
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.
*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.
## 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