项目review规则

• 尊重他人，就事论事，对事不对人，毕竟每个人都写过烂代码；
• PR 中的每一个 commit log 都应该可以和代码对应，方便 review；
• 尽量不要发太大的 PR，以免引起 reviewer 的恐慌；
• 建议保证一个 PR 的粒度和专注，最好不要出现一个 PR 里又有重构又加新 feature 的情况，同样容易引起 reviewer 的恐慌；
• 提 PR 之前请确保在本地或测试环境一切正常；
• reviewee 如果接受 reviewer 提出的修改意见，需要在修改提交以后知晓 reviewer，常见的做法可以是在 review comment 处回复（并带 commit 链接）；
• 评论中至少出现一个 lgtm 且保证 ci 通过之后 PR 才可以被合并；（注：lgtm 即 looks good to me 的缩写）
• PR 合并者与提交者不能是同一个人；
• PR 需从一个特定分支（分支的名字尽量能表达代码的功能）发往上游的 master 分支；
• Model 的部分，如不紧急需要unittest；
• Web 的部分，如不紧急需要webtest；
• PR 合并后如引起 bug 或功能异常，并经查确为此 PR 引起，提交者需请全组攻城湿喝饮料或吃冰棍（由被请者决定）；
• 将 fork 的仓库与上游同步时，应使用 git fetch upstream && git rebase upstream/master （或 code sync -r ），而不是 git merge 或 code sync （这里code是指面向 CODE 系统的一个命令行工具），以保持清晰的提交历史，并防止覆盖他人的修改；
• 注意安全问题，对于 SQL 拼字符串，模版中有 |n 的，以及处理用户输入等地方都需要仔细review，更多请参考 Web 安全开发指南