Phabricator/differential

来自开放百科 - 灰狐
(版本间的差异)
跳转到: 导航, 搜索
(以“Phabricator [code review|代码复审]] 应用模块:differential。 使用 Arcanist 命令行工具创建 Differential diff. ==...”为内容创建页面)
 
(简介)
 
(未显示1个用户的11个中间版本)
第1行: 第1行:
[[Phabricator]] [code review|代码复审]] [[phabricator_applications|应用模块]]:differential。
+
[[Phabricator]] [[code review|代码复审]] [[phabricator_applications|应用模块]]:differential。
  
使用 Arcanist 命令行工具创建 Differential diff.
+
==简介==
 +
Phabricator 支持两个代码复审工作流程:“审查/Review”(推送前)和“审计/Audit”(推送后)。
 +
 
 +
使用 [[Phabricator/arcanist|Arcanist]] 命令行工具创建 Differential diff.
 +
 
 +
工程师可以在页面上非常方便的针对每一段(单行或者多行)代码进行交互讨论;负责审查的工程师可以接受代码改变,可以提出疑问要求原作者继续修改,可以提出自己不适合以推出该代码审查,等等。只有代码被明确接受之后才能被工程师提交到服务器端的代码库,这一点集成到提交工具中强制执行。基本理念就是凡是被很多人不断重复的好的习惯,要将其自动化,绑定到工具之中。以“Don’t make me think”的方式来推广好的practice。
 +
 
 +
==功能==
 +
[https://phabricator.webfuns.net/book/phabricator/article/reviews_vs_audit/ 审查(Review)和 审计(Audit)工作流程之间的差异]
 +
 
 +
==审计==
 +
[https://phabricator.webfuns.net/book/phabricator/article/audit/ 审计用户指南]
 +
 
 +
小团队可以设置一个简单审计工作流程:
 +
*创建一个新项目 “代码审计”
 +
*为提交创建一个新的全局 Herald 规则,对于没有 “Differential 修订”的每个提交, 触发由 “代码审计” 项目进行的审计(这将允许您部分或全部转换成审查)。
 +
*让所有的工程师加入到 “代码审计” 项目。
 +
这样,每个人都将看到每个提交的审计请求,但如果有人批准了它,请求将会消失。 实际上,这强制实现了 “每个提交都应该有人检查” 的规则。
 +
 
 +
ps: [https://phabricator.webfuns.net/book/phabricator/article/herald/  Herald]规则通常用于:通知用户,添加审阅者,启动审计,对象分类,阻止提交, 执行 CLA 和运行构建。
 +
 
 +
==指南==
 +
 
 +
==图集==
  
 
==链接==
 
==链接==
*[http://phabricator.huihoo.com/book/phabricator/article/arcanist/ Arcanist User Guide]
+
*[https://phabricator.webfuns.net/book/phabricator/article/differential/ Differential 用户指南]
*[https://secure.phabricator.com/book/arcanist/ Arcanist Technical Documentation]
+
  
 
[[category:phabricator]]
 
[[category:phabricator]]
 
[[category:code review]]
 
[[category:code review]]

2018年3月7日 (三) 10:44的最后版本

Phabricator 代码复审 应用模块:differential。

目录

[编辑] 简介

Phabricator 支持两个代码复审工作流程:“审查/Review”(推送前)和“审计/Audit”(推送后)。

使用 Arcanist 命令行工具创建 Differential diff.

工程师可以在页面上非常方便的针对每一段(单行或者多行)代码进行交互讨论;负责审查的工程师可以接受代码改变,可以提出疑问要求原作者继续修改,可以提出自己不适合以推出该代码审查,等等。只有代码被明确接受之后才能被工程师提交到服务器端的代码库,这一点集成到提交工具中强制执行。基本理念就是凡是被很多人不断重复的好的习惯,要将其自动化,绑定到工具之中。以“Don’t make me think”的方式来推广好的practice。

[编辑] 功能

审查(Review)和 审计(Audit)工作流程之间的差异

[编辑] 审计

审计用户指南

小团队可以设置一个简单审计工作流程:

  • 创建一个新项目 “代码审计”
  • 为提交创建一个新的全局 Herald 规则,对于没有 “Differential 修订”的每个提交, 触发由 “代码审计” 项目进行的审计(这将允许您部分或全部转换成审查)。
  • 让所有的工程师加入到 “代码审计” 项目。

这样,每个人都将看到每个提交的审计请求,但如果有人批准了它,请求将会消失。 实际上,这强制实现了 “每个提交都应该有人检查” 的规则。

ps: Herald规则通常用于:通知用户,添加审阅者,启动审计,对象分类,阻止提交, 执行 CLA 和运行构建。

[编辑] 指南

[编辑] 图集

[编辑] 链接

分享您的观点
个人工具
名字空间

变换
操作
导航
工具箱