处理 GIT 中的并行重复分支

Question

如果有人能帮助我，我会很感激。

最初，我有两个功能分支：branchA 和 branchB

确定branchB属于branchA，于是我迅速愉快地将branchB合并到branchA中。

现在，branchA 继续增长，在合并之后，相当多的新功能被添加到原来的 branchB 中（现在是 branchA + branchB）。

有一段时间我保持原来的分支 B 活着，并尽我最大的努力让它与添加到分支 A 的任何功能保持同步，以便（理想情况下）在两个分支上具有相同的更改，并最终将分支 B 合并到Master，然后将 branchA 也合并到 Master 中。

然后它击中了我：

• 除了维护 branchB 的副本之外，是否真的有充分的理由这样做？
• 这种重复的情况是否会导致冲突，这是一种好的做法吗？
• 从理论上讲，branchA 现在不是一个独立的功能分支并且...
• ...称分支B为“僵尸分支”公平吗？

我知道这个问题可能看起来很愚蠢，但我正试图了解在这种情况下理想的流程是什么，考虑到它会影响大型项目，因此非常欢迎任何建议和 cmets！

Answer 1

除了维护 branchB 的副本之外，是否有充分的理由这样做？

我认为没有任何充分的理由浪费时间和精力来维护一个重复的分支。在完美世界中，每个功能只有一个分支。
随着功能变得越来越大并且代码分布在不同的文件中，将您的更改保存在两个不同的分支中变得非常困难，最重要的是您不需要这样做，因为在某些时候您想要合并所有内容掌握。

这种重复的情况是否会导致冲突...

这真的取决于你如何让 branchB 与来自 branchA 的更改保持同步，如果你 cherry-pick 每次提交，不，但如果你以某种不同的方式移动更改，很可能你会遇到冲突。

...这是一种好的做法吗？

我不认为任何让你的生活变得更艰难的事情都是“好习惯”。
我认为每个公司对“好”和“坏”做法都有自己的规则，但在我工作过的所有公司中，这都被认为是不好的。

从理论上讲，branchA 现在不是一个独立的功能分支，而且......称 branchB 为“僵尸分支”是否公平？

好像branchA是一个独立的特性分支，branchB不需要的时候应该删除，以免造成混乱。