【发布时间】：2012-12-18 03:43:04
【问题描述】：
如果您有一个从 master 分支出来的分支，然后在其中开发了您的功能......当涉及到合并回 master 时，我听说过 2 种不同的方法：
- 先将 master 合并到 feature 分支，然后再将分支合并回 master。
- 将您的分支合并到 master。
谁能告诉我哪种方法更好，第一种方法是否有实际好处？
或者有没有更好的方法？
【问题讨论】：
【发布时间】：2012-12-18 03:43:04
【问题描述】：
我想这取决于 ;-)
需要考虑的一些事项：
- 合并后是否需要功能分支？如果是这样，将
master合并到其中以及合并回master可能会很有用。如果不是，那么如果您仍然要删除它，那么合并到功能分支并没有太大意义。 - 您可以破坏
master分支的本地工作副本吗？如果没有，您应该避免将代码合并到master中，这可能会导致您需要手动解决大量冲突。如果没问题，请继续。
一般来说，我会说这取决于你如何使用 git。
由于我一般只临时使用功能分支，并且在成功完成一个功能并将它们合并到master 后删除它们，我通常直接合并到master 并在之后删除另一个分支。
另一方面，我可以想象可能在某些情况下，反过来可能会有用。但只要没有强有力的理由，我会尽量避免它。一次合并就足够了；-)。
【讨论】：
理论上没有区别。您在一个分支中有一组更改，您正在与另一个分支中的一组更改相结合。这些变化最终在哪里并不重要。
在实践中，最好将更改合并到功能分支中，因为它为您提供了一个隔离的地方来解决冲突。如果功能分支已经开发了很长时间，这一点尤其重要，因为通常会在第一次提交后解决微妙的冲突。
最好的方法是定期从主分支更新到特性分支，减少特性开发结束时发生冲突的可能性。
【讨论】：
假设您从 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 进行合并提交来解决冲突。如果你犯了任何错误，你将打破主人。这很糟糕。
【讨论】：