沒有開發分支的特性分支模型的Git分支策略

Question

我們的團隊在解決關於我們案例的最佳策略時遇到問題。

我們的情景

1. 每一個特徵有一個分開的分支
2. 我們有來自master創建release分支，準備下一個版本。將在下一個版本中的功能將合併到此分支中。但是，正如我所說的，在最後一刻，某些功能可能會退出該版本。
3. 每一個特徵，在最後時刻，可以得到的版本（release分支）出來。我們不確定下一個版本會具有哪些功能。所以，我們不能使用類似develop分支的東西（如Git流程中所述）。
4. DBA團隊在生產中執行一些獨立於版本的腳本。這些腳本在master上提交，因爲它們已經在生產中。

我sugestion

我們正在考慮所產生的版本測試團隊從release分支。如果它的一切就OK了，我們正在考慮到release分支合併爲master，使用此版本的標籤從master分支把一個版本標記（如1.0）上master和生成的版本。

在主唯一commmits不在版本承諾是DBA團隊的SQL提交。因此，從release生成的版本等於master。

但這不批准整個團隊。

恐懼

他們有一個關於我們將使用哪一個分支來生成EAR恐懼。在master分支中生成的EAR文件與測試的EAR文件不完全相同，因爲這是從release（另一個分支）生成的。

另一個擔心來自我的團隊是關於某個commiting（或合併功能）直接進入master和主機產生的版本有這個意想不到的承諾。他們肯定會在某個時候發生。怕

部分是因爲DBA的承諾「爛攤子」主的歷史。主服務器只需要提交版本，但我不知道如何組織獨立於版本的DBA團隊的SQL腳本。這些SQL腳本與下一個版本一起發佈是沒有意義的，因爲這些腳本已經在生產數據庫中執行了。

解決方案（臨時？）

的解決方案，現在，是生成release分支版本，並在生產中使用相同的EAR從release分支。之後，release分支將合併爲master，並且將創建新的release分支。 DBA SQL腳本將繼續在master中提交。

我的意見

我不喜歡這種做法，因爲：

1. 我們失去了機會，有穩定的歷史master僅含版本提交的版本標籤。我想爲此提供解決方案，但我不知道要解決DBA SQL腳本的問題。
2. 恐懼也是基於過去的合併錯誤，他們使用（複雜的）Subversion作爲版本控制。
3. 版本標籤將分佈在不同release分支上的存儲庫中。
4. 基於某些開發者直接在master上做錯事的恐懼。
5. 該解決方案與幾乎所有現有的分支模型都相反，因爲它不會生成主版本。我擔心現在看不到的其他問題。

即使有了這些擔憂，我也無法消除恐懼，並且我理解他們的恐懼。我想知道有沒有人對我們的問題有不同的解決方案。

更新

最初的恐懼之後，我們從master分支產生的版本。在release分支上進行測試後，我們將release分支合併到master中，並從那裏生成版本。所以，所有版本標籤都保留在master分支中。

如果在release分支中檢測到某些問題，我們刪除此分支並生成一個新分支，而沒有問題的功能。

與某些特定功能無關的DBA腳本是獨立執行的，現在保存在另一個存儲庫中。

Answer 1

首先，這需要有一些相當好的過程規範才能工作，聽起來像你有一個多組件應用程序，其代碼基本上沒有以一種方便的方式構造。

我做這樣的事情： - 主分支源的真理，幷包含所有已完成的功能，只有構建主/建築/不管得到合併/摘櫻桃這個 -release_x.y是分支代表該版本的最終產品。

在開發週期的開始，從以前的版本分支

創建發佈分支的每個功能團隊已經從主建立自己的分公司，在任何時候，他們開始了他們的功能工作。功能團隊中的任何人都可以檢查此分支。

當某個功能完成後，相應的提交將被選中/合併/壓縮到主設備中，並刪除功能分支。

由於功能已確認發佈，提交將被櫻桃採摘/合併/壓縮到發佈分支中。構建是從發佈分支完成的。

如果您對以前版本有錯誤修復，請使用該版本的分支進行初始修復。至少，您需要選擇變成主人，您可能必須選擇其他功能和/或發佈分支，具體取決於影響分析

功能開發的另一種方法是在給定的時間點根據主人創建單獨的團隊回購。取決於您的偏好，我喜歡單獨的可以獨立分支或標記的回購（例如敏捷項目中的衝刺）。它還使各個功能團隊能夠更輕鬆地在可能存在依賴關係的地方交換正在進行的工作。無論哪種情況，您可能都需要將更新內容帶入您的團隊/功能回購，但這是可行的。

然而，你可能只是有很多耦合，如果刪除，可能使你的源代碼樹更容易的複雜的源代碼樹來管理