1. 关于Gitlab

Gitlab是一个类似Github/Bitbucket的代码托管软件，有一个显著不同是Gitlab提供下载版，可安装到各类Linux和Docket上，使得公司内部可以搭建私有的Gitlab环境，而不用登录公网。

她非常适合那些不愿把源代码提交到公网上如Github/Bitbucket/Gitlab.com等平台的组织，对于国内用户而言，可能还有个原因就是访问上述几个国外网站时网络质量不稳定，甚至有时干脆无法访问。

2. Code Review步骤

  1. master分支作为稳定分支，进入Gitlab上设置该分支只有master角色的用户才能合并其他分支并push到远程仓库。通常由master角色用户根据软件稳定性来合并。
  2. develop分支是开发主分支，类似master分支，只有master角色的用户才能操作。
  3. 假设用户test开发功能或修复bug时从develop创建出新分支，假设任务号为100，则新分支命名为branch_refs100。待新分支上工作告一段落时比如发生以下情况，可进入下一步：
    • 工作完毕想要合并进develop
    • 每积攒200行～500行代码左右。如果1000行才开展Review会使得每次占用太多时间。
    • 重要代码
    • 困惑代码
  4. 提交最新代码到新分支branch_refs100，并push到远程仓库。
  5. 进入Gitlab的项目主页：
    • 点击merge_requests->New merge request，在source branch->Select source branch中选择branch_refs100，在Target branch中选择develop，也就是说源分支是From，目标分支是To。
    • 点击Compare branches and continue，进入新网页后填写Title和Description，并在Assignee中选择邀请Review的用户名，Milestone和Labels最好也有。
    • 点击Submit merge request。
  6. test用户以社交方式通知邀请Review的用户，比如admin。
  7. admin用户登录Gitlab后在右上角会发现分配给自己的Review任务，她进入到该Merge Request网页：
    • 点击Changes->Side By Side，可看到branch_refs100和目标分支的区别代码，右侧是提交者的新分支代码。默认网页中仅显示差异部分代码，想要看全部代码需点击Expand All。
    • admin用户逐行检查差异，一旦发现有改善点，可在右侧该行行号位置点击类似回复图标，然后填入Comment。
    • 全部Review完成后通知test用户。
  8. test用户访问该次merge request网页，点击Changes、逐个查看admin提交的comment：
    • 如果同意则相应修改代码，并点击该Comment的Resolve discussion，表示解决。
    • Tips：点击Resolve discussion后面的第2个图标，可快速跳到下一个admin留下的Comment。 * 如果不同意，请继续回复，或与admin用户口头沟通，令其撤销该comment。 * 如上操作直到所有Comment得到确认，提交并push到远程仓库中branch_refs100分支。并再次创建merge request，告知admin用户再次Review。
  9. admin用户确认新一轮的merge request后，通过git命令手动合并branch_refs100进入develop分支，并经过test用户同意后删除branch_refs100分支。

至此本次Code Review结束。下面摘录Gitlab官方说明。

3. Gitlab官方工作流：Typical flow

Excellent code depends on rigorous review. At GitLab, every change is reviewed using this flow:

  • A developer merges a change in their feature branch and tests it. When they’re happy they push, and merge a merge request.
  • The developer assigns the merge request to a reviewer, who looks at it and merges line and design level comments as appropriate. When the reviewer is finished, they assign it back to the author.
  • The author addresses the comments. This stage can go around for a while, but once both are happy, one assigns to a final reviewer who can merge.
  • The final reviewer follows the same process again. The author again addresses any comments, either by changing the code or by responding with their own comments.
  • Once the final reviewer is happy and the build is green, they will merge.

To find out more about the importance of code quality, considerations for teams of different sizes and stages, and details on how we develop at GitLab while using GitLab, watch our webcast, “Code Review: A Business Imperative” on demand.

4. 后记