Git Merging Branch成Master

Question

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

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

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

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

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

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

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