Phabricator 拉/合并请求答案

【问题标题】：Phabricator pull/merge requestPhabricator 拉/合并请求
【发布时间】：2016-01-08 19:28:36
【问题描述】：

是否可以在 Phabricator 中以 bitbucket 样式进行拉取请求？

例如。分支出一些现有分支，然后创建拉（合并）请求以合并新分支？

我看到 Phabricator 差异工具只允许将一些手动输入的差异提交到某个分支。这是唯一的方法吗？

【问题讨论】：

标签： bitbucket phabricator

【解决方案1】：

您可以将git 和arc 混合在一起，但这确实违背了arc diff 的用途。

您可以改用audit，尽管我还没有详细说明下面的内容（我也没有使用过审计）。

下面，我试图解释我们的新工作流程，从git-flow 到使用git 和arc diff 的改编版本。

背景

在我们开始使用Phabricator 之前，我们使用了Gitlab 并创建了合并请求。这些将由另一个开发人员进行审查。我们使用JIRA，我们的工作流程包含一个review required 阶段，该阶段在进入测试之前进行了多项检查。

此时，我们已将分支推送到远程，请求审查并等待测试发生（我们混合了手动和自动测试）。

审核通过并通过测试后，功能分支将合并到origin/develop。

新的工作流程

我们的新工作流程不再需要在 Gitlab 中创建合并请求，尤其是用于审核。

我的团队仍然使用包含git-flow 的工作流，但是，我们引入了arc diff 命令。这会在 Phabricator 中创建差异。开发人员将他的分支推送到远程，但没有提出合并请求。

我们在创建差异时运行以下命令（合并到origin/develop）

git checkout -b feature/foo
git add <files>
git commit -m "A useful commit message"
git push origin feature/foo
arc diff origin/develop # this creates the diff within diffusion

一旦审核被接受，我们不会合并（或arc land）分支，我们等待所有测试进行。这使我们能够在测试失败时更新差异，并且审查的开发人员可以轻松查看哪些提交需要审查。

一旦测试通过，我们就可以简单地合并，使用gitlab 合并请求或命令行。我们通常运行 arc close-revision <revision-id> 来关闭 Phabricator 本身的修订。

补充说明

我相信arc diff 的理念是您不推动本地分支。相反，您创建了一个diff，它会显示扩散。这被归类为pre-push 工作流。

Phabricator 还有一个包含审计的post-push 工作流。您可以通过修改提交消息来简单地将提交标记为可供审核。

【讨论】：

GitLab CI 可以针对合并请求运行测试、lints 和审查应用程序（将功能分支部署到动态环境），因此无需手动操作相同的工作流程。我看不出为什么 Phabricator 的 arc diff 工作流程更好，我只是看到它提供了相同的功能，但需要更多的手动工作，因为 GitLab 会自动完成。
是的。没错，我们使用了这些功能，但我们一直在寻找一种工具，可以为我们提供提交块历史记录，因此我们可以轻松区分提交，因为有时在初始审查后会添加额外的提交。我了解 Gitlab 也允许您在提交之间进行区分。 Phabricator 只是我们正在评估的另一个工具。

【解决方案2】：

否，请参阅 https://secure.phabricator.com/T5000 以跟踪此功能请求。

Differential 的主要输入应该是 Arcanist，Phabricator 命令行工具。它包装了 git 并提供 lint、unit 和其他预提交检查，有助于减少审查代码所花费的时间。例如，它可以在提交审核之前发布补丁和修改代码。

https://secure.phabricator.com/book/phabricator/article/arcanist/

【讨论】：