当我试图让我的功能分支与主分支保持同步时，我必须不时地将主分支合并到我的功能分支。
如果这样的合并成功，它会在功能分支上创建一个新的提交吗？
如果此类合并失败，我将不得不手动解决合并冲突。在这种情况下，进行包含
的提交是一个好主意或者我应该将我为解决合并冲突所做的更改以及功能分支上的工作分别划分为不同的提交？ 是否会对以后的
产生影响一般来说，我如何安排从主分支合并到我的功能分支并在我的功能分支上提交我自己的工作？
答案 0 :(得分：4)
从master到功能分支的合并确实通常会为合并生成新的提交。您可以设法对此规则进行例外处理，但仅在功能分支尚未对其进行任何提交时或多或少。如果您想绝对确定创建提交，您可以与no-ff选项合并。
我的建议是将尽可能少的更改放入合并提交中。有几个相关的原因。
首先，合并应该代表两行工作的汇合。合并提交消息通常类似于＆＃34;将master合并到some_feature＆＃34 ;;如果你做了额外的工作，你需要一份提交信息，列出你所做的无关事情，并且有可能 - 甚至可能 - 当有人在寻找你的改变时，这些信息会被遗漏后面。
就此而言，合并提交的默认日志输出不包含补丁。你可以得到一个，但它是一个3（或更多）的补丁，很多难以阅读。因此，如果您希望能够轻松检查您的更改，请不要将它们添加到合并中。
下一步：在路上你可能会想知道什么变化引入了一个bug。通常，过于复杂的提交会导致太多事情会降低工具的有效性，从而帮助您缩小范围（例如bisect）。并且＆＃34;从大师合并打破了我的功能分支＆＃34;可能有一个非常不同的分辨率而不是＆＃34;我添加到我的功能的最新工作打破了我的功能分支＆＃34;。
还有一种情况，git类型假设合并只是一个合并。我主要考虑的是rebase操作，并且可能很少或者永远不会提到你会通过这样的合并进行重组。但是，如果你这样做，并且如果合并包含不相关的更改，那么你将遇到不必要的问题。
偶尔也会发生手动＆＃34;重做＆＃34;合并;如果你在合并中包含不相关的工作，那就更难了。