将master分支合并到功能分支会在未来引起一些问题吗?

时间:2017-05-03 15:18:01

标签: git

如果我将分支B2合并到分支B1中,合并是否会影响两个分支可能仍会随着在将来单独创建或分别提交的新提交而增长?

例如, 通常将功能分支合并到主分支中。 但是当我正在处理功能分支时,协作者正在更改主分支。我想更新我的功能分支,所以我想将主分支合并到功能分支。合并是否会在将来引起一些问题,例如,

  • 当我尝试拉入主分支进行更新时,或
  • 当我继续处理功能分支并在功能分支上添加新提交时?

感谢。

4 个答案:

答案 0 :(得分:1)

将主分支合并到功能分支是一种常见做法。它使功能分支与主分支中的最新更改保持同步。

这样,它可以在功能开发完成时最大限度地降低冲突风险,并且是时候将功能分支合并回主分支。

答案 1 :(得分:1)

它实际上是将主分支上的更改定期合并到您的功能分支的典型工作流程的一部分,因为它使功能分支与合作者一直在做的事情保持合理的最新状态,并减少当您最终准备将功能更改合并到主分支时,可能会出现混乱的合并冲突。

答案 2 :(得分:1)

由于无论出于何种原因,你没有从两个人告诉你这是一个普遍的做法的事实推断它:

不,通常不会导致问题。

如果它引起了问题,那就不常见了。

我说它不会一般导致问题,因为可能会出现一些奇怪的情况,其中一系列因素会导致虚假的合并冲突,也许有些情况下你描述的合并类型是一个因素。但这是一个例外,而不是规则。

针对您描述的合并类型的唯一论据是,有些人不喜欢看到从master重复合并到长期存在的功能分支。这些合并有利于分支维护者,而不是负责master的整体项目维护者;所以当后者有一个巨大的自我时,他们认为这是一个问题。

下意识的反应是反叛而不是合并到功能分支中。有时可以,但有两个潜在的问题:

1)一旦功能分支被推送到原点,将它重新定位通常是一个坏主意。请参阅"从上游rebase恢复"在git rebase文档中有关原因的一般解释

2)即使分支没有推送,重新定位也可以提交实际构建不干净的中间提交(除非你愿意重新测试和每次你修改时修复每一个)。可以说是"脏"提交是一件坏事。

另一个选择是执行合并以进行测试(以确保您不会偏离master),然后使用reset退出合并。为了帮助这可以创建重复的冲突解决工作,他们发明了git rerere

当然仍然意味着你可能有中间提交,不能干净地构建和测试(因为它们是针对合并然后被取出而构建和测试的)。

在我看来,退出合并然后使用rerere来减轻损害只是一个复杂的解决方案。我没有问题进行合并并将其保留到位。

答案 3 :(得分:0)

通常,您希望数据在一个方向上流动,如feature =>主。这是rebase可以派上用场的地方。

      A---B---C topic
     /
D---E---F---G master

然后重新加入

             A'--B'--C' topic
             /
D---E---F---G master

Src:https://git-scm.com/docs/git-rebase