Use GitLab's Merge Request for code review

One of the undeniable practices in the quality built-in engineering practice that has been used so far is code review. It is used as an effective measure to improve the quality of product delivery and improve the efficiency of the development process. Git is currently a popular source code management tool. If your team has selected GitLab as a hosting tool, then in this article you can learn how to conduct code reviews through GitLab's Merge Request and the existing we follow Code review best practices to improve workflow.

Before we discuss how to conduct code reviews, let's review the general principles of code reviews.

General principles of code review

• Code reviews are an integral part of any development process-print them out and put them on the wall to remember. You can refer to the code review you wrote before and you need a list revolution!
• Code reviews are performed on small, logically complete code fragments, such as functions, tasks, bug fixes, improvements, etc.
• Only the approved code will be sent to the testing department.
• All developers of the project will conduct code reviews regardless of their level.
• All developers of the project should pass the code review, regardless of their level (junior developers should also review the code of experienced intermediate and senior experts).

Next, we will introduce how to use the tools provided by GitLab for code review.
The merge request in GitLab refers to the operation of merging code from one branch to another.

The main parameters involved in creating a Merge request are:

• source branch
• target branch
• title
• description

• assignee

  
  
   

  

  content_Creating-merge-request.png

Operation steps when using Merge Request:

1. Write code and push it to a separate branch.
2. Create merge requests for the main development branch. Assignee and those mentioned in the description field and comments will notify the merge request via email. If you need a developer's attention, you can @@ 名 名 developer in the description field.
3. Wait until MR is accepted or rejected and provide comments about necessary repairs.
4. Participate in discussions about repairs. (GitLab allows replying to comments)
5. repair.
6. Push the changes to your branch.
7. Open a new merge if the last MR is closed (if the merge request is not closed, it will be automatically updated until the last commit).
8. Consolidate requests by annotating or otherwise reporting implemented fixes.

 

content_reviewing-merge-requests.png

To whom should Merge Request be assigned

For merge requests, their allocation depends on various factors. Depending on the number of people and professional level of the project, there are different options. Therefore, if you are the only developer on the team, please assign a merge request to yourself.

Otherwise, please talk to another independent developer in the project and let him review each other's code. Document review is usually necessary because after you do this, you will ensure that other developers can use your code when necessary.

If you are two developers of the project, please assign merge requests to each other. If there are three or more developers, you are free to choose.

Your team can conduct code reviews at the beginning and end of the workday or as required. The team can decide when to conduct a code review, and the most important thing is continuous collaboration between team members.

Use the code review generated by Merge Requests to discuss how to perform more elaborate process management.

Author: Jane book Mr. CC
link: https: //www.jianshu.com/p/198915ac64ba
Source: Jane books