Phabricator使用向导¶
Phabricator代替redmine，成为昂信嵌入式的最新的QA系统。 Phabricator是facebook.com的团队开发的，对于软件团队协作的意义巨大。 之所以从redmine迁移过来，是因为Phabricator支持代码提交的 前审核流程 。
前审核的概念：工程师修改的代码不会直接进入git版本库，而是先提交至QA； 再由另外（至少）一名工程师进行审核。直至审核通过后，方能够提交至git。 相当于一个人做作业，一个人检查错误，将显著提高准确率。 因此，这一套工作流程，保证我们的代码库的所有代码都是经过较有经验的工程师检验过， 提高代码的质量。
wiki¶
审核流程¶
审核的操作工具是Phabricator的 arc 工具，目前只支持命令行。 具体安装和操作方法在此不表，请参考文档。
我们仅将公司内部使用前审核的最佳实践流程给出。 审核流程如下图所示：
![digraph codereview {
clone -> r1;
r1 -> Diff1;
subgraph cluster_task {
label="branch\n T123";
Diff1 -> Diff2 [label="reject"];
}
Diff2 -> r2 [label=accept];
subgraph cluster_master {
node[shape=box,style=rounded]; r1;r2;r3;
label = "branch\n master";
r1 -> r2 [minlen = 3];
r2 -> r3 ;
}
subgraph cluster_task2 {
label="branch\n T77";
D1;
}
r1 -> D1;
D1 -> r3[label=accept,minlen=3];
}](_images/graphviz-7592526744ff38b62ec6d384f7b743b54b74814f.png)
首先，git clone 下载版本库，切换到主分支master分支。 我们此时位于master分支的某个版本r1之上。
工程师计划完成T123编号的任务，首先要建立分支，分支名就是 T123 ， 分支名称与任务编号一致。建立新分支是必要的，因为arc创建更改的基本单位是分支。 即使一个分支上有多次git提交，arc只会创建一个 更新编号 。 换言之，你arc新建了一份更改，此时不变分支，新建git提交，再arc diff， 还是提交到前一次的更改当中。
开发完成后，arc diff 命令 提交前审核代码，生成Diff1，并且指定某工程师为其审核。审核者登录QA，进入 Differencial ,查看修改的代码， 如果认为存在问题的话，可以直接在QA进行批注。 在此例子中，Diff1被拒绝，所以工程师需要继续修改， 再次提交，生成Diff2. Diff2 被审核者批准。 之后，开发者 arc land 命令， 提交代码到git，生成新版本r2.
如果在处理T123的过程中，突发任务T77，需要同一名开发者紧急改bug。 此时需回到r1。因为Diff1、Diff2都还没有提交到git， 我们需要回到远程git库的一个状态（一般都是最新状态）。 这一步是必须的，因为arc提交更改是以分支为单位的。
然后类似的：建立分支名 T77 ，arc diff 提交更改， 指定审核人。通过审核之后，arc land 命令 提交代码到git，生成新版本r3. 这个命令是phabricator文档推荐的方法，批处理封装了git命令， 但是实际上傻瓜化的方法会丧失灵活性。 所以我们还是建议直接用 git push