Git分支模型策略

Question

我們正在嘗試遵循gitflow分支模型，但有一個轉折點 。

我們有四個可以部署產品的服務器環境，每個服務器都有一個目的：開發，內部測試，外部測試和生產。

• DevServer ，開發人員在開發時測試他們的不同功能。 開發人員無法在他們的計算機上進行本地測試，他們必須在DevServer上進行更改才能進行測試
• TestServer ，一旦開發人員完成，QA測試人員就會測試多個功能
• ReleaseServer ，在將版本移至生產環境之前對其進行單獨測試
• ProductionServer 。 生產服務器

我們試圖盡可能簡化合並/沖突解決方案，因此我們創建了兩個不屬於gitflow模型的額外分支。

正常的gitflow分支

• 開發
• master （匹配'ProductionServer'）
• featureXXX
• releaseXXX （每周版本部署到'ReleaseServer'）

但這兩個分支也不標准，可能需要改變......

• dev-release （DevServer的副本）
• 測試版 （TestServer的副本）

然后過程如下：

• 開發人員從'develop'創建'featureXXX'
• 多個開發人員將他們不同的“功能”合並到“dev-release”分支中，並且“dev-release”分支被發布到“DevServer”，然后所有開發人員都可以測試他們的不同功能。 並非所有這些功能都將在下一個版本中
• 一旦開發人員對上面的開發測試感到滿意，他們就將'featureXXX'合並到分支'test-release'中，並將其部署到'TestServer'。 並非所有功能都屬於同一個下一個版本。
• 一旦對featureXXX進行'TestServer'測試，開發人員就可以將他們的featureXXX關閉為'develop'。
• 開發人員然后創建一個新的'releaseXXX'或將他們的'featureXXX'合並到現有的'releaseXXX'中。
• 'releaseXXX'分支部署到'ReleaseServer'並進行測試。
• 一旦'releaseXXX'測試簽署，'releaseXXX'將合並到develop和master中，並部署到'ProductionServer'

我們搞亂了整個gitflow模型嗎？

這是我們的分支流程：

Answer 1

為了回答你的問題，不是你沒有弄亂gitflow模型 - 更多地擴展它以滿足你的需求。

通過將環境耦合到給定的分支，您可以在構建版本時為自己提供更大的靈活性。 即假設您有兩個非依賴功能（功能1和功能2）正在進行中，這兩個功能都已合並到您的“TestServer”分支中。 如果功能1測試失敗，功能2仍然可以在沒有功能1的情況下進一步發展 - 這是因為您合並到'TestServer'是單向合並 - 沒有任何結果，沒有歷史記錄。 相反，您的Feature 2分支將合並為“develop”並最終合並為“master”。

我們正在為自己采用/制定類似的策略。 我們的關鍵要求是適應不可避免的櫻桃采摘功能 。 請注意，我們的解決方案雖然相當復雜，但它是為企業應用程序設計的，可作為多個業務所有者擁有的多個服務的平台，並利用多個內部框架。

環境

• QA：讓開發人員確保他們的功能是可測試的。
• 階段：讓項目經理/測試經理在UAT測試之前通過各種“業主”進行抽煙測試
• UAT：由'業主'進行全面測試和商業簽署
• BETA：僅僅是對部署/發布的測試
• 現場：..

這些環境分為兩類，“測試中”（QA，階段和UAT）和“生產”（BETA和LIVE）。

分行

功能優先級可以經常更改，從測試問題到監管限制/請求。 為了適應這種情況，創建了多個分支來表示環境/類別，如下所示：

• Master：代表最后一個生產版本
• Release-Candidate：下一個產品發布的一系列功能
• UAT：代表UAT環境
• 階段：代表'QA'和'舞台'
• Feature-xxx：用於功能開發

我們還根據需要使用Master的HotFix分支，並在“預生產”分支中准備生產版本（更正錯過的版本增量等 - 次要內容）。

我們正在使用的分支圖表：

分支和合並/ WorkFlow

1. 我們總是從Release-Candidate分支新功能，因為此分支始終包含“Committed for production”功能。 一旦做出生產承諾，沒有什么能夠超越。

2. 一旦功能准備好進行測試，它就會合並（單向）進入“舞台”。 這會觸發CI構建並部署到QA。

3. 如果QA服務器看起來穩定，則開發人員會觸發自動部署到Stage。

4. 如果需要更改，請在功能中進行更改並重復。 如果可以進行業務測試，則從Feature合並到UAT。 這部署到UAT。

5. 如果功能未通過業務測試，則進行功能更改並重復。 如果功能延遲，則不采取任何措施。 如果功能正常並簽名，則合並到Release Candidate。

6. 一旦收集（1個或多個）功能在Release-Candidate中，通過從Release-Candidate合並到Master（通過Pre-Production）來觸發生產部署。

7. 部署失敗，然后是HotFix。 如果正常，請部署到Live。

我們使用TFS的工作流程如下所示：

發布工作流程

最后，每個環境/類別的部署將如下所示：

Answer 2

Git是一個版本控制系統。 它維護源代碼及其更改。 開發在開發階段停止。 之后，源代碼不應該改變。

當您將項目移動到下一個階段（測試，發布，生產）時，您不應該提供源代碼，而是從標記版本構建二進制文件，因為：

• 源代碼在不同的環境中不會改變，
• 兩個構建可能提供兩個不同的二進制文件（更改依賴項）
• 維護不同版本將很困難。 例如，
  • 多個版本的項目需要支持
    • 框架項目
    • A / B測試
    • ...
  • 修正錯誤。 想象一下，當測試服務器上的新版本發布時，您需要從生產中進行修補。 此修補程序需要通過相同的流程（測試，發布，生產）。 因此，您需要使用錯誤修復覆蓋測試分支，並在合並回新版本之后。 這不是顯而易見的，不是必要的，並且可能導致最初具有不同的代碼。 實際上，每次合並，在開發之后，源代碼可能會有不同的風險。 而且你可能需要在prod中解決合並沖突。

所以它可能不會干擾git-flow模型，但我認為這些點值得考慮。 實際上，我不是git-flow策略的忠實粉絲。 如果你有一分鍾​​給這些機會：

https://barro.github.io/2016/02/a-succesful-git-branching-model-considered-harmful/ https://trunkbaseddevelopment.com/