VSTS Git在子分支合并回主分支后将孙分支合并到主分支

我们有一个长期运行的分支branch1，从master分支出来，它正在进行一个完整的回归测试，这需要一段时间

在测试过程中，我正在开发一个需要在branch1中进行更改的特性，称之为branch1a，它是branch1的分支。我还在努力，但应该尽快完成

今天早上，branch1测试已经完成，它被合并回master。我们在使用VST。我不太清楚它是如何合并的（重基、挤压等）。有一个PR列出了branch1的一组提交和其他PR。看起来它在主历史记录中显示为1个提交

现在我真的不知道我完成后该怎么办，我的母分支有点消失了，但有点没有。如果我创建一个PR和master，我会更改400个文件，如果我创建PR和branch1，我会更改12个文件

看起来合并将在branch1分支之前使用公共父级，而不是我将branch1a从branch1分支出来的地方，这似乎会导致很多问题（尽管从技术上讲，实际的最新文件中只有很少的更改）

在这里，用重基取代合并更有意义吗？我的提交应该非常清晰地重放现在的主控内容（如果我正确理解rebase的话）

---

我们在VST中有一些策略，不能直接提交给master——我们需要使用PRs。我不确定我是否可以创建一个使用rebase的PR…也许我应该将master、branch2分支，并将我的分支重新设置为branch2，然后从branch2创建一个PR到master？

像git那样思考会有帮助；因此，从这个意义上说，

branch1

并没有“消失”。它要么已被删除并消失，要么未被删除且未消失。从你的描述来看，我认为是后者

确实，您应该了解分支是如何与

master

组合的。我怀疑它刚刚合并了。根据您如何看待master的历史记录，您可能（也可能不）将合并的结果描述为“一次提交”。（国际海事组织，壁球的文件在这方面可能令人困惑。）

那个歌手有第二个父母吗？如果是这样，那就是真正的合并。如果不是，那就是壁球（这会让事情变得更难）。如果只是一次提交，那就不是简单的重基（但壁球实际上只是一种特殊类型的重基，所以我想这就是扯淡）

如果是真正的合并，一切都很好。您可以将

branch1a

合并到

master

；最多这可能会使冲突解决变得更具威胁性。如果您想将其分解为更小的冲突解决工作（或者如果您只想在分支拓扑中保持对称感），可以将

branch1a

合并到

branch1

，然后再次将

branch1

合并到

master

我不希望重定基础会让事情变得更容易，如果任何

branch1a

提交被推到远程回购，那么我建议不要重定基础。无论如何，重新设置基准的原因是，如果您想要一个更线性的历史，有些人会发现它更干净（即使它可能会创建不可构建的中间状态）

---

至于你的最后一段。。。你用这个想法把事情弄得太复杂了。没有必要。

将branch1提交到主控中的提交只有一个父级。我所有的更改都已推送到远程branch1a分支，但我是目前唯一一个使用该功能的人。我们仍然有branch1，所以两步方法（branch1a->branch1->master）听起来更好。