在gitflow工作流中處理拉請求的工作流（帶有不經常發佈的版本）？

我們之前的工作流程與gitflow類似，所有東西都是分開的，主人總是反映生產。當準備發佈時，功能分支會合併到主設備中，修復不同功能之間的可能衝突，爲發佈創建標籤，推送給主設備，就是這樣。在gitflow工作流中處理拉請求的工作流（帶有不經常發佈的版本）？

因此，現在我們想要將拉入請求集成到此工作流中，但讓分支的開發人員負責修復衝突。然後，這個想法仍然是主分支，然後對一個叫做releaseX的新分支做一個pull請求，在那裏所有進入下一個版本的新代碼都是。

問題是，當新功能和其他功能之間的releaseX存在衝突時，開發人員如何解決這些問題？在github中進行合併是不可接受的，將releaseX合併到特性分支中也不是這樣（它會拉入不相關的特性，並且會使特性難以進入生產）。

我們最終創建了一個僅用於合併的分支，比如resolution/releaseX_my_beautiful_feature。

（目前，以下更像模型（而不是gitflow），連續部署和版本的沒有真正的概念githubflow的，是不是我們的最佳解決方案。）

做你們採取什麼樣的工作流程當同時使用pull-requests和release時？

來源

2017-04-04 Sofia

git-flow for release修復的基本思想實際上是一個單獨的修補程序分支，您可以在修復某些bug並在修復它們之後創建新版本。所以對我來說，這聽起來像你沒有這樣做，這就是爲什麼你有這些概念問題。請糾正我，如果我錯了。 – ckruczek

我們確實有一個發佈分支，這是進入新版本的功能和熱修復被合併到的地方。問題是，當發生衝突和時，我們正在使用pull請求，這是開發人員在不將特徵分支合併到發佈分支的情況下修復這些衝突的唯一方法，即..在那裏它將繞過pull請求功能，並且不將發佈分支合併到功能分支中，開發人員可以從功能分支中創建特定分支，在發佈分支中合併並修復衝突。 – Sofia

在[Atlassian]（https://www.atlassian.com/git/tutorials/making-a-pull-request）中，他們提供了有關如何使用gitflow工作流程維護請求工作流程的有趣說明。如果您覺得有幫助，請看看並告訴我們。 – ckruczek

由於@ckrusek表示Atlasssian在不同類型的工作流程上有很好的文檔。關於gitflow +拉請求工作流，他們推薦的是：

功能岔開發展
功能做一個拉要求開發
發佈岔開發展（分支命名約定：釋放 - *或釋放/ *）。發佈分支僅用於準備發佈，尚未開發的任何功能都會推遲到下一發布週期。
合併發佈分支進入主和發展
維護/熱補丁分支岔開主
維護/熱補丁分支合併到主和發展

當然，還是有沒有辦法不要將無關的功能混入開發到我們的功能分支中。

基本上，拉請求工作流意味着更頻繁的發佈，並且爲了處理這些，我們需要有特徵標誌，以便在需要時關閉在生產中不經常測試的功能。這個模型給我們帶來的是一個包含發佈概念和管理方式的工作流程。

來源

2017-04-05 15:57:27 Sofia

在gitflow工作流中處理拉請求的工作流（帶有不經常發佈的版本）？

回答

相關問題