一旦發布准備好並合並到開發和主版本中，如何處理GitFlow（或其他過程）中的錯誤修正

Question

從https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow ：

一旦發布准備好發布，它將被合並到master中並進行開發，然后發布分支將被刪除。

現在已經完成了合並：假設我們現在突然面臨生產不穩定（多么不幸！），master和develop分支現在暫時與生產環境不同步，發布（比如說1.1）被推遲了。 。 后來，我們發現了需要一個或多個修復程序的問題：在您看來，如果知道master和development現在與prod不同步，處理一個或多個錯誤修復的最佳方法是什么？

• 我應該從development創建一個新的發行分支（並以1.2命名），然后將變更從master轉變為最新的生產發行標簽（比如1.0）嗎？ 如果是這樣，什么是最好的方法，以便可以盡可能保留更改的歷史記錄？
• 對於那些具有發行周期實際經驗的人：您是在發行后合並發行分支還是在發行前樂於合並？

編輯：總而言之，這個問題實際上是關於澄清在發布周期之后以及在將該版本部署到環境之前處理錯誤修復時所需的工作量。 目的是闡明在部署到生產環境（基本上是從發行分支而非母版發行到環境）之后，通過執行發行周期合並（合並到母版/開發中）可以節省多少動作。

Answer 1

您鏈接的文章中指出

主分支存儲官方發布歷史記錄[...]

因此， 根據定義 ， release分支合並到master就是發行。 您描述的工作流中不是這種情況，因為您還有另一個production實例，該實例可以在不久的將來從master獲取更新。

話雖如此，我認為您所處的最佳方法是從production創建一個hotfix分支，解決您的問題並將其合並到production以及develop和master 。 然后可以按計划進行從母版的“發布”，同時盡快解決您的production問題。

如您所鏈接的文章中所述，該方法非常接近GitFlow修補程序工作流程。 由於您唯一要做的是錯誤修復，因此與完整版本相比，修復程序工作流程更為合適。