当试图使我的功能分支与主分支保持同步时，我不得不不时将主分支合并到我的功能分支。我应该如何安排从主分支合并到我的功能分支并在我的功能分支上提交我自己的工作？
是否正确，如果这样的合并成功，它会在功能分支上创建一个新的提交？
如果这样的合并失败，我将不得不手动解决合并冲突。在这种情况下，它是一个好主意，以提交其中既包括
还是应该分开我为解决合并冲突和功能分支上的工作而进行的更改以进行不同的提交？ 它使我自己的特性分支工作以后
一般来说，我应该如何安排从主分支合并到我的特征分支中，并在我的特征分支上提交我自己的工作？
确实从master合并到一个功能分支通常会产生一个新的合并提交。你可以设法规定一个例外，但只有在功能分支还没有提交任何提交时，或多或少。如果你想绝对确定创建了一个提交，你可以合并no-ff选项。
我的建议是把尽可能少的变化合并为提交。有几个相关的原因。
首先，合并应该代表两行工作的合流。合并提交消息通常类似于“合并主机到some_feature”;如果你做了额外的工作，你需要一个提交信息，列出你所做的不相关的事情，并且有可能 - 甚至有可能 - 当有人在稍后寻找你的改变时，这些信息将被错过。
对于这一点，合并提交的默认日志输出不包含修补程序。你可以得到一个，但它是一个3（或更多）的补丁，它是难以阅读的很多。所以，如果你想能够轻松检查你的变化，不要将它们加入到合并中。
下一步：在路上您可能会关心知道哪些更改引入了错误。通常情况下，提交过多的提交操作太多会降低工具的有效性，这些工具可帮助您缩小范围（如bisect）。和“从主人合并打破我的功能分支”可能有一个非常不同的分辨率比“我添加到我的功能的最新作品打破了我的功能分支”。
也有一些情况，其中git类型假定合并只是合并。我主要想到的是rebase操作，而且很少或者从来没有出现过，你会通过这样的合并来重组。但是，如果你这样做，并且如果合并包含不相关的更改，则会产生不必要的问题。
它也偶尔会发生，你必须手动“重做”合并;再次，如果你在合并中包含了不相关的工作，这很难。