是否可以在Phabricator中以bitbucket风格进行拉取请求？
EG。分支一些现有分支，然后创建拉（合并）请求以合并新分支？
我看到Phabricator差异工具只允许向某个分支提交一些手动输入的差异。这是唯一的方法吗？
答案 0 :(得分：3)
不，请参阅https://secure.phabricator.com/T5000来跟踪此功能请求。
差分的主要输入应该是Arcanist，即Phabricator命令行工具。它包装git并提供lint，unit和其他precommit检查，有助于减少审查代码所花费的时间。例如，它可以在提交审核之前发出补丁并修改代码。
https://secure.phabricator.com/book/phabricator/article/arcanist/
答案 1 :(得分：2)
您可以将git和arc混合在一起，但它确实违反了arc diff的使用方式。
您可以使用audit代替，但我还没有详细说明下面的内容（我还没有使用过审核）。
下面，我尝试使用git-flow和git来解释我们的新工作流程，从arc diff到适应版本。
在我们开始使用Phabricator之前，我们使用了Gitlab并创建了合并请求。这些将由另一位开发人员审核。我们使用JIRA，我们的工作流程包含一个review required阶段，在进行测试之前会有几个检查。
此时，我们已将分支机构推到远程，请求审核并等待测试（我们混合了手动和自动测试）。
一旦审核被接受并且测试通过，功能分支就会合并到origin/develop。
我们的新工作流程无需在Gitlab内创建合并请求，尤其是在审核时。
我的团队仍然使用合并git-flow的工作流程，但是，我们已经引入了arc diff命令。这在Phabricator中创建了差异。开发人员将他的分支推送到远程，但没有提出合并请求。
我们在创建diff（合并到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工作流程，其中包含审计功能。您可以通过修改提交消息来标记准备好进行审核的提交。