欢迎大家赞助一杯啤酒🍺 我们准备了下酒菜：Formal mathematics/Isabelle/ML, Formal verification/Coq/Agda, C++/Erlang/Lisp
Phabricator/differential
来自开放百科 - 灰狐
（版本间的差异）
小 (→链接) |
小 (→简介) |
||
| （未显示1个用户的10个中间版本） | |||
| 第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 和运行构建。 | ||
| + | |||
| + | ==指南== | ||
| + | |||
| + | ==图集== | ||
==链接== | ==链接== | ||
| − | *[ | + | *[https://phabricator.webfuns.net/book/phabricator/article/differential/ Differential 用户指南] |
| − | + | ||
[[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 和运行构建。
[编辑] 指南
[编辑] 图集
[编辑] 链接
分享您的观点
