git - Git 合并分支到主控

Question

如果您有一个从 master 分支出来的分支，然后在其中开发了您的功能......当涉及到合并回 master 时，我听说过 2 种不同的方法：

1. 先将 master 合并到 feature 分支，然后再将分支合并回 master。
2. 将您的分支合并到 master 中。

谁能告诉我哪种方法更好，第一种方法是否有实际好处？

或者如果有更好的方法？

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中的合并提交解决冲突。如果您在解决过程中犯了任何错误，您可以将它们回滚而无需任何直接修改来掌握。这很好。

如果您选择 (2)，您将通过直接对 master 进行合并提交来解决冲突。如果你犯了任何错误，你将打破主人。这是不好的。

Answer 2

我想这取决于;-)

需要考虑的一些事项：

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

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

由于我通常只临时使用功能分支，并且在成功完成一个功能并将它们合并到后删除它们master，因此我通常直接合并到master并在之后删除另一个分支。

另一方面，我可以想象，在某些情况下，反过来可能会有用。但只要没有强有力的理由，我会尽量避免它。一次合并就足够了；-)。

Answer 3

从理论上讲，没有区别。您在一个分支中有一组更改，您正在与另一个分支中的一组更改相结合。这些变化最终在哪里并不重要。

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

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