吉特（Git）：我怎样才能完全依赖尚未合并的PR？

Question

目的是保持工作流程高效和历史记录干净。

常见问题

我要介绍的几个小功能将相互依赖，并且我不想在等待第一个合并的第二个PR上受阻（我希望它位于单独的分支中）。

为了澄清，我需要添加2（+）个功能： feature-1和feature-2 。 feature-2取决于feature-1 。 它们都将驻留在不同的分支上，并且可能需要几天的时间才能接受feature-1的PR。 我想在等待的同时处理feature-2 （一个单独的分支），与此同时， feature-1可能需要进行一些必要的更改，这些更改应渗透到feature-2 。

3个解决方案 ：

• 我可以从feature-1分支feature-2
• 我可以创建一个新的“具有several-features ”的分支，然后将分支合并到那里，然后再将其合并为master 。
• 我可以分支一个本地master在其中我可以乐观地合并feature-1 ，然后在需要传播对-1的更改时可以重新合并回feature-2 。

我当前的解决方案是后者：

1. 从master创建分支feature-1

2. 编写代码，推送它，然后启动PR

3. 在等待合并时将其本地合并到master

4. 从那个feature-2分支（现在这取决于feature-1 ）

5. 如果要求对feature-1更改，请对其进行修复，乐观地合并回master ，合并回feature-2 ，并在feature-1遇到feature-2需要的东西IE时始终执行此操作，即始终通过本地（-仅）主版。

我不喜欢我的主人的历史与官方的历史有所不同，但是由于git就像仅附加（大多数）的vcs，而且我认为commit是一种关联操作...他们的历史实际上就是相同？

Answer 1

我希望我理解了这个问题。...但是我将解释如何轻松地处理此工作流程。

如果从feat1开始feat2，则在处理feat2时，您可能会遇到以下情况：

场景1：feat1有了一些额外的复兴...。

git rebase feat1

场景2：feat1 感动了 （可能是重新设置了）。 这涉及更多。 我们甚至不确定feat1的修订版本是否已重设而不会发生冲突，我们现在所要做的只是分支已移动 ，我们一无所知（开发人员可能已决定重新开始，因此原始修订版本与之无关）到新的）：

git rebase --onto feat1 old-tip-of-feat1 feat2 # ask git to move feat2 discarding all old revisions of feat1, and put them on top of feat1

实际上，它不一定是分支的旧提示，它可能是feat2历史上的feat1的最新版本。

方案3：feat1被合并为master。 这很简单：

git rebase master

这些是基础。