目标是保持工作流程高效和历史记录整洁。
常见问题
我想介绍几个相互依赖的小功能，并且我不想在第二个PR上等待第一个合并而被阻塞（我希望它位于单独的分支中） 。
为澄清起见，我需要添加2（+）个功能：feature-1和feature-2。 feature-2取决于feature-1。它们都将生活在不同的分支机构上，可能需要几天的时间才能接受feature-1的PR。我想在等待的同时在单独的分支feature-2上工作，与此同时feature-1可能需要进行一些必要的更改，这些更改应该会渗透到feature-2。
3个解决方案：
feature-2分支feature-1 several-features”，然后将分支合并到其中，然后再将其合并为master。master，我乐观地将feature-1合并到其中，然后在需要传播来自feature-2的任何更改时合并回到-1。 / li>
我当前的解决方案是后者：
从feature-1创建分支master
编写代码，将其推送，然后启动PR
在等待合并之前将其本地合并到master
从那个feature-2分支（现在这取决于feature-1）
如果在feature-1上请求更改，请对其进行修复，乐观地合并回master，合并回feature-2，并在feature-1 feature-2所需的IE总是流经master的本地（仅）版本。
我不喜欢我的主人的历史与官方的历史有所不同，但是由于git就像一个仅附加（大部分）的vcs，而且我认为commits是一种关联操作...他们的历史将真的一样吗？
答案 0 :(得分：2)
我希望我理解这个问题。...但是我将解释如何轻松地处理此工作流程。
如果从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
这些都是基础。