4

我对 git 还很陌生，甚至对 Phabricator 也很陌生，我正试图在我的项目早期建立一个干净的工作流程。据我了解，使用 git 的正确做法是为每个功能创建一个新分支，在分支中实现它，然后将分支合并到 master 中。效果很好，没问题。

进入 Phabricator 并预推代码审查。我创建了一个分支，我们称它为“B”，实现一些东西，运行“arc diff”将其放入 Phabricator 的差异审查系统，等待批准，最后运行“arc land”推送到主存储库。到目前为止，一切都很好。但是，我不想在等待审阅者回复我时暂停进一步的开发。

所以，我有我的提交审查，我想开始研究一个细化或依赖的特性。我创建了一个子分支，我们称之为“SB”，然后开始工作。我让 SB 准备发送审核，但 B 尚未获得批准。“arc diff”看起来会将现有提交与我不想要的新更改结合起来 - 这是一个新更改，而不是对旧更改的更新。我尝试使用“arc diff B”，它可以工作，我在差分中获得了一个新版本，其中仅包含新更改。B 获得批准，我在 B 上运行“arc land”以提交它。这行得通。

SB 获得批准，我在 SB 上运行“arc land”来提交它。我得到一个用法异常 - Arcanist 将这两个版本都视为在 SB 而不是在 master 中。我尝试切换到 master 并运行更新，然后再试一次。同样的错误。我尝试使用 --revision 标志来实现这两个更改（即使其中一个确实已经实现了）。我得到合并冲突。我解决并提交合并冲突，然后重试。我再次得到完全相同的合并冲突。

我最终想到在 SB 上尝试变基，最终让“弧地”正常工作。所以，我有一个技术上可行的解决方案，但这对我来说似乎很笨拙和尴尬。有没有更好的方法来避免手动变基的需要，只是为了让 Arcanist 认识到不，我已经登陆的修订版不是我现在登陆的内容的一部分？

4

2 回答 2

2

通常，使用 Arcanist，您将在 master 之外创建每个分支。这将防止第 3 段中描述的问题。

工作流程会是这样的：

  1. 拉取master的当前代码
  2. 用于arc branch B创建本地分支
  3. 对您的更改进行编码并用于arc diff区分您的代码
  4. 再次checkout master并拉取当前代码
  5. 用于arc branch SB创建本地分支
  6. 对您的更改进行编码并用于arc diff区分您的代码

B一旦登陆到 master 上，仍然需要进行合并或变基。

如果您不想以SBmaster 为基础并且真的希望它基于 off B，那么您将需要通过使用来指定基础arc diff B 这也将解决第 3 段中描述的问题。不幸的是，此选项不会阻止第 3 段中的合并冲突4. 你将不得不SB在着陆前变基以防止这种情况发生。

于 2014-09-29T17:11:04.107 回答
0

以下对我有用：

  1. git checkout master
  2. git checkout -b task-1
  3. arc diff
  4. git checkout -b task-2
  5. arc diff --create task-1

更改后task-1：

  1. git checkout task-2
  2. git rebase task-1
  3. 解决任何冲突

一旦task-1获得批准：

  1. git checkout task-1
  2. arc land task-1
  3. git checkout task-2
  4. git rebase origin/master
  5. 解决任何冲突
于 2021-01-07T17:29:31.277 回答