我正在使用「Git Flow」分支模型，具有主分支和開發分支。我正在開發一個重要的新版本，所以我的開發分支與我的主分支大不相同。這在任何時候需要在master分支上製作熱補丁並將其重新合併爲開發時都會產生問題。幾乎總是有衝突，並且正在變成真正的痛苦。當開發分支與主分支非常不同時管理修補程序？
什麼是最好的管理方式？對我來說，手動開發小修補程序更改會更容易，然後在準備就緒時將所有內容合併到主服務器中，而無需將主機合併到開發中。這可能嗎？
我對這種情況的一般工作流程是創建分支master修復問題。一旦準備就緒，將其合併回master，然後合併master到develop。
這假設您的錯誤修復幾乎是它需要在兩個分支中更改的代碼之間的一對一。如果是這種情況，你總是可以嘗試git merge -s ours master（見man-page）到develop，所以develop分支優先。
我使用類似的流程來管理我正在開發的一個開源項目上的錯誤修復版本。 master始終位於需要應用錯誤修復的位置之前，所以我從需要修復的標記創建分支，應用修復和發佈，然後重新標記併合併到master。這會由於版本號而導致衝突，但可以使用上面的命令來避免。
希望有所幫助。
爲什麼不'git merge -s我們的hotfix-2.2'其中2.2是我編造的 – basarat
獲取一些從一個分支到另一個分支的最簡單方法是cherry-picking。
假設你在master修補程序有提交哈希HASH並且要採取修補程序到您的devel分支，做一個git checkout devel後跟一個git cherry-pick HASH。而已。
如果你想利用從master所有變成devel，就可以實現與
git checkout devel
git rebase master
如果你有相反的情況（你在devel分支開發中作出修補程序並且想在devel完全合併到master之前將此修復解決爲master），工作流程非常類似。假設修補程序有散列HOTFIX_HASH，這樣做：
git checkout master
git cherry-pick HOTFIX_HASH
現在，犯存在於master和devel。爲了解決這個問題，類型
git checkout devel
git rebase master
，並提交將於devel消失，因爲它已經存在於master。
請注意''git cherry-pick'創建了一個不同的提交。隨後將'devel'分支合併到'master'中會因此而發生衝突。該解決方案僅適用於「改版工作流程」。 –
正如@IvanBorisenko所暗示的那樣，如果您正在與其他人一起開發開發工具，那麼您會希望'git merge master'而不是rebase以避免重寫歷史記錄。在第二種情況下，會出現合併衝突。 – gsf
在發出'checkout'和'cherry-pick'命令之前，我是否需要推送給主服務器？ –
我通常遵循這個guide這在大多數情況下非常合適，並避免與市長衝突問題和大更改。
如果你能在feature分行工作，只是之前合併它們在development到release分支的創建（這意味着你實際上是準備釋放）...這種方法應該避免最合併的衝突，那麼你的經驗。
由於分支變更將發生在feature-breaking分支上，所以在此分支被合併到開發中時，您可能只有一次衝突。您也可以隨時將development合併到release分支中，以便隨時更新。
你也會很酷，合併到development所有hotfix-branch es你有最小或無衝突。
我之前在鏈接上分享的指南非常重視從不從development到master或向後合併。始終通過release分支處理您的版本。
你有沒有考慮[cherry-picking]（http://technosophos.com/content/git-cherry-picking-move-small-code-patches-across-branches）而不是將'master'合併到'develop' ？ –
默認情況下，使用非FF合併，如果您將開發人員開發爲主人，開發人員的頭將不會進行主人更改，但主人將會進行開發更改。那是你要的嗎？ – Andy
@安迪 - 我基本上只是想用發展來取代主人。我不希望它抱怨主變更沒有被合併到開發中，等等。 – TaylorOtwell