我们有一个长期运行的分支机构1，从主机分支，正在进行完整的回归测试，这需要一段时间。
在测试时，我正在研究一个需要更改branch1的功能，将其称为branch1a，它是branch1的分支。我还在努力，但应该尽快完成 TM 。
今天早上，branch1测试结束了，它被合并回主人。我们正在使用VSTS。我不完全确定它是如何合并的（rebase，squash等）。有一个PR列出了branch1的一堆提交和其他PR。看起来它在主历史记录中显示为1次提交。
现在我不确定在我做完之后该做什么，我的父母分会有点不见了，但事实并非如此。如果我创建一个PR与master，我会更改400个文件，如果我创建它与branch1，我会更改12个文件。
看起来合并将使用公共父级，在branch1分支之前，而不是我从branch1分支branch1a，这似乎可能会导致很多问题（但从技术上讲，只有少数问题）实际最新文件的变化。）
这里的rebase而不是合并会更有意义吗？我的提交应该非常干净地重放现在的主人（如果我理解正确的rebase）。
我们在VSTS中有策略，以便我们无法直接提交到master - 我们需要使用PR。我不确定我是否可以创建一个使用rebase的PR ...也许我应该分支master，branch2，并将我的分支重新绑定到branch2，然后从branch2创建一个PR来主？
答案 0 :(得分：0)
像git一样思考会有所帮助;所以从这个意义上讲，branch1并非“有点消失”。它已被删除但已消失，或者它尚未被删除且未消失。根据你的描述，我认为后者。
要确定，您应该了解分支如何与master结合使用。我怀疑它刚刚合并。根据您查看主历史记录的方式，您可能（或可能不会）将合并的结果描述为“单个提交”。 （在这方面，壁球的文件可能会令人困惑，IMO。）
那个单一的提交有第二个父母吗？如果是这样，这是一个真正的合并。如果不是，那就是壁球（这会让事情变得更难）。如果它只是一个提交，它不是一个简单的rebase（但是壁球实际上只是一种特殊类型的rebase，所以我认为这是分裂的。）
如果这是真正的合并，一切都很好。您可以将branch1a合并到master;至多这可能会使冲突解决更加令人生畏。如果要将其分解为较小的冲突解决工作（或者如果您只想在分支拓扑中保持对称感），可以将branch1a合并到branch1然后合并{{ 1}}再次branch1。
我不希望rebase让事情变得更容易，如果任何master提交被推送到远程仓库，那么我建议不要使用rebase。无论如何，改变的原因是你想要一个更线性的历史记录，有些人会发现它更清晰（即使它可能会产生无法建立的中间状态）。
至于你的最后一段......你用这个想法让自己太复杂了。没有必要。