當試圖使我的功能分支與主分支保持同步時，我不得不不時將主分支合併到我的功能分支。我應該如何安排從主分支合併到我的功能分支並在我的功能分支上提交我自己的工作？
是否正確，如果這樣的合併成功，它會在功能分支上創建一個新的提交？
如果這樣的合併失敗，我將不得不手動解決合併衝突。在這種情況下，它是一個好主意，以提交其中既包括
還是應該分開我爲解決合併衝突和功能分支上的工作而進行的更改以進行不同的提交？ 它使我自己的特性分支工作以後
一般來說，我應該如何安排從主分支合併到我的特徵分支中，並在我的特徵分支上提交我自己的工作？
確實從master合併到一個功能分支通常會產生一個新的合併提交。你可以設法規定一個例外，但只有在功能分支還沒有提交任何提交時，或多或少。如果你想絕對確定創建了一個提交，你可以合併no-ff選項。
我的建議是把儘可能少的變化合併爲提交。有幾個相關的原因。
首先，合併應該代表兩行工作的合流。合併提交消息通常類似於「合併主機到some_feature」;如果你做了額外的工作，你需要一個提交信息，列出你所做的不相關的事情，並且有可能 - 甚至有可能 - 當有人在稍後尋找你的改變時，這些信息將被錯過。
對於這一點，合併提交的默認日誌輸出不包含修補程序。你可以得到一個，但它是一個3（或更多）的補丁，它是難以閱讀的很多。所以，如果你想能夠輕鬆檢查你的變化，不要將它們加入到合併中。
下一步：在路上您可能會關心知道哪些更改引入了錯誤。通常情況下，提交過多的提交操作太多會降低工具的有效性，這些工具可幫助您縮小範圍（如bisect）。和「從主人合併打破我的功能分支」可能有一個非常不同的分辨率比「我添加到我的功能的最新作品打破了我的功能分支」。
也有一些情況，其中git類型假定合併只是合併。我主要想到的是rebase操作，而且很少或者從來沒有出現過，你會通過這樣的合併來重組。但是，如果你這樣做，並且如果合併包含不相關的更改，則會產生不必要的問題。
它也偶爾會發生，你必須手動「重做」合併;再次，如果你在合併中包含了不相關的工作，這很難。