Git Merging Branch成Master

Question

如果你有一个分支，你从主人那里分出来然后开发你的功能......当谈到合并回主人时，我听到了两种不同的方法：

1. 首先将master合并到功能分支中，然后将分支合并回master。
2. 将您的分支合并为主。

任何人都可以告诉我哪种方法更好，第一种方法是否有实际好处？

或者，如果有更好的方法？

Answer 1

假设你从master创建了 feature-sev ，同时我创建了 feature-eric 。我的分支修改了与你相同的文件;事实上，它碰巧以我们的git客户端不够聪明的方式重叠。我先完成开发并合并我的更改。

在这种情况下，您将不可避免地被提示解决冲突。

CONFLICT (content): Merge conflict in stackoverflow.html
Automatic merge failed; fix conflicts and then commit the result.

如果您使用（1），将master合并到分支并确保一切都很好，您将通过 feature-sev 中的合并提交来解决冲突。如果您在解决过程中出现任何错误，可以将其回滚，而无需对master进行任何直接修改。这很好。

如果您使用（2），您将通过直接向master进行合并提交来解决冲突。如果你犯了任何错误，你就会打破主人。这很糟糕。

Answer 2

我想这取决于; - ）

需要考虑的一些事项：

• 合并后是否需要功能分支？如果是这样，将master合并到其中以及合并回master可能会有用。如果没有，如果要删除它，合并到功能分支没有多大意义。
• 你可以打破master分支的本地工作副本吗？如果没有，您应该避免将代码合并到master，这可能会导致您需要手动解决许多冲突。如果没问题，请继续。

总的来说，我会说这取决于你如何使用git。

由于我通常只暂时使用功能分支，并且在成功完成功能并将它们合并到master后删除它们，我通常会直接合并到master并删除其他分支。

另一方面，我可以想象可能是可能有用的情况，反之亦然。但只要没有强有力的理由我就会尽力避免它。一次合并就足够了; - ）。

Answer 3

理论上，没有区别。您在一个分支中有一组更改，您将与另一个分支中的一组更改组合在一起。这些变化的结局并不重要。

实际上，最好将更改合并到功能分支中，因为它为您提供了一个孤立的地方来解决冲突。如果功能分支已经开发了很长时间，这一点尤为重要，因为通常会在第一次提交后解决细微的冲突。

最好的方法是从主数据库到功能分支定期更新，减少功能开发结束时发生冲突的可能性。