Gitflow：將發布錯誤修復合並回主開發

Question

我的問題是圍繞 gitflow 過程中的一個非常具體的點（如此處所述）。

我已經將release/1.2錯誤修正合並到master ，並進行了適當的標記。

除了歷史看起來如何，從release/1.2回合並與從master回合並到develop之間有什么區別。

我已經嘗試了兩種方法，在我簡單、人為的示例中，正如我所料，我發現develop沒有區別。

這有危險嗎？ 我以后會遇到麻煩的問題嗎？ 我錯過了一些明顯的東西嗎？ 我懷疑答案可能與已進入master其他功能有關，但目前應該不在develop中。

合並發布以開發：

合並主開發：

Answer 1

如果您將master合並回您的 develop，您將在您的 develop 分支中將所有merge branch release/xy into master合並merge branch release/xy into master合並提交中，而在合並release/xy分支本身時，您只會獲得真正的更改。

當然，這或多或少是一個表面問題。 但是合並方向通常只是從develop到master ，而不是相反。

除了上述合並提交使您的develop分支混亂之外，沒有真正的危險。 如果您堅持流程，那么master中永遠不應該有不在develop ，因為熱修復和發布分支應該始終合並到您的develop和master 。

Answer 2

我懷疑答案可能與已進入master其他功能有關，但目前應該不在develop中。

無論如何， master提交都會進入下一個修補程序合並的develop 。 如果有真正的代碼更改，可能會出現意外結果並扭曲主機修復內容。

合並穩定分支（ master在gitflow）進入開發分支（ develop中gitflow）是已知的各種git的工作流的方式。 Bbitbucket Server（Atlassian 出售的商業解決方案）具有自動分支合並的功能。 由於存在一些錯誤修復，Git 項目本身總是將分支maint合並到master中。

所以我真的不明白 gitflow 的作者選擇另一種方式的原因。 可能沒有真正的理由，這只是一個偶然的決定。

Answer 3

這有危險嗎？ 我以后會遇到麻煩的問題嗎？ 我錯過了一些明顯的東西嗎？

沒有危險； 沒有問題； 你不會錯過任何東西。 將master合並回develop是（恕我直言）稍微好一點的方法，並且沒有缺點。 無論您選擇哪種方式，您最終都會在develop獲得相同的合並提交總數。 區別僅在於這些合並提交何時結束。 如果合並release回來第一你沒有得到全部的release ，以master ，當你做了修補程序合並提交，直到后來，所有在一桿。 如果您重新master develop您會立即看到最近的合並提交。 但是將master合並回develop有一個更大的優勢：

在任何時候，確保master中的所有更改在存在時也在develop或release很重要。 （唯一的一次，他們應該永遠是不同步的是完成時release或hotfix的分支。）也許，以確認最簡單的方法master的同步增長是確保尖端（上提交）在master總是在develop ，或在它存在時release 。 您可以輕松編寫腳本以定期運行，並在不正確時通知您。 如果您不能期望master的提示提交永遠在release那么該腳本會更加復雜。