我已经疯了，今天公司新来的小白提交了好了问题代码到项目仓库，最要命的是项目在线上跑不起来时费劲好大力气，检查了各种可能性，甚至还一度怀疑是不是数据库、应用服务器有问题呢。花了半个小时才发现是代码问题，追踪到版本管理才发现是新来的小白提交了很多问题代码！！！
然后又花了很多时间为了把这个被小白污染的仓库清理干净，因为在他提交的前前后后都会其他的代码更新。
都怪我，为了着急上线没怎么做测试就匆匆上线；都怪我，没有检查大家提交的代码就急忙更新。业务中断两个小时，看来离滚蛋不远了。吃键盘的心都有了！！！
----- 华丽分割线 -----
这就是不做代码评审的下场！！！
可是代码评审很难搞，特别是使用 SVN 或者把 Git 当做 SVN 来用的团队。
我们希望项目的主仓库只有负责人才有权限操作，项目组成员对代码的任何修改都要经过审核后才能合并到主仓库。这样才能确保上述事故不会发生。
----- 呼啦啦分割线 -----
其实只要我们善用 Git 工作流就可以轻轻松松实现代码的评审功能。
以码云为例，基本流程如下：
假设项目主仓库 A/Project1 ，该仓库只有项目负责人（小红）具备写权限，项目成员只读
新来的小白复制 A/Project1 仓库到 "小白/Project1" （在 A/Project1 页面点一下 Fork 按钮）
然后小白开始制造各种 Bug ，修改无数代码
写了一天的代码，小白觉得可以交差了，然后创建了个 Pull Request 请求把当前的改动合并到主仓库
项目负责人小红看到有人提交了 Pull Request ，打开小白修改的文件一看，惊呼：这是什么垃圾代码！！！
一时间，小白哭，小红怒，天色阴暗，可能要下雨了。。。
如果你还不熟悉 Git 工作流的操作，请前往 https://gitee.com/ 体验。
欲知后事如何，请听下回分解。