我是git的新手，甚至是Phabricator的新手，我正试图在我的项目早期设置一个干净的工作流程。据我了解，使用git正确的做法是为每个功能创建一个新分支，在分支中实现它，然后将分支合并到master中。效果很好，没问题。
输入Phabricator并预先推送代码评论。我创建了一个分支，让我们称之为“B”，实现一些东西，运行“arc diff”将其放入Phabricator的差异审查系统，等待批准，最后运行“arc land”以推送到主存储库。到现在为止还挺好。但是，在等待审稿人回复我的时候，我不想暂停进一步的开发。
所以，我有我的提交审核，我想开始改进或改进功能。我创建了一个分支，我们称之为“SB”，然后开始工作。我准备SB发送审查，B尚未批准。 “arc diff”看起来会将现有的提交与我的新更改结合起来，这是我不想要的 - 这是一个新的更改，而不是对旧的更新。我尝试使用“arc diff B”而且它有效，我在Differential中获得了一个新版本，仅包含新的更改。 B获得批准，我在B上运行“arc land”提交。这很有效。
SB获得批准，我在SB上运行“arc land”提交。我得到一个使用例外 - Arcanist认为这两个版本都在SB中，而不是在master中。我尝试切换到掌握并运行更新，然后再次尝试。同样的错误。我尝试使用--revision标志来完成两个更改（即使其中一个确实已经登陆）。我得到合并冲突。我解决并提交合并冲突，然后再试一次。我再次得到完全相同的合并冲突。
我最终得到了在SB上尝试变基的想法，最终让“弧形土地”正常工作。所以，我有一个技术上有效的解决方案，但这对我来说似乎很尴尬和尴尬。有没有更好的方法来避免手动变基的需要，只是为了让Arcanist认识到不，我已经登陆的版本不是我现在登陆的一部分？
答案 0 :(得分：2)
通常，使用Arcanist，您将创建主分支的每个分支。这将防止第3段中描述的问题。
工作流程如下：
arc branch B创建本地分支arc diff来区分您的代码arc branch SB创建本地分支arc diff来区分您的代码在B登陆主人后，仍然需要进行合并或变更。
如果你不想让SB离开主人，并且真的希望它基于B，那么你需要使用arc diff B指定基数这也是解决第3段中描述的问题。不幸的是，这些选项不会阻止第4段中的合并冲突。您必须在登陆前重新定位SB以防止这种情况发生。
答案 1 :(得分：0)
以下对我有用：
git checkout mastergit checkout -b task-1arc diffgit checkout -b task-2arc diff --create task-1在改变在由task-1：
git checkout task-2git rebase task-1在task-1已被批准：
git checkout task-1arc land task-1git checkout task-2git rebase origin/master