如何使這個MKS源代碼完整性工作流程適應Git？

Question

請考慮以下情況：

• 目前使用MKS源完整性（是的，它傷害）。
• 每週兩次，一些開發人員在開發分支中檢入一個功能（或其中的一部分）。
  • 一個功能的簽入與其他功能的簽入交織在一起。
  • 例如：轉1，3，5是用於特徵A，修訂版2爲特徵B，第4版用於特徵C.
• 每週一次，驗證功能在生產分支檢查。
  • 大多數情況下需要合併來自未驗證功能的更改。
  • 示例：功能A（從上方）投入生產，但不具備功能B和C，因此我們不想採用第1,3,5（revard 2和4）版，但第3版可能也需要與第二次修訂版在開發過程中的變化合並;合併將被撤消。

遷移到Git的（耶！）。什麼工作流程會尊重這個約束？

我已經讀了很多關於它的內容，每一個工作流程似乎都是基於這樣的假設：在時間t，特徵A，B和C將會完成。如果不是的話，我估計是延遲了。

在我的情況下，有沒有趕上完成功能的時間，永遠。每個開發人員都在處理一個或多個功能。如果它已經準備就緒，它將投入生產。如果不是，繼續細化。每個星期都會有生產生產。極少數情況下，沒有新的代碼更改進入生產環境，但仍然是建立的。大多數情況下十幾種功能都在生產中。

希望它很清楚。讓我知道你是否需要更多細節！

認爲

（編輯）工作流程：在私有分支上的功能

1. 工作
2. 推首次來發展，作爲一個單一提交
3. 在專用分支繼續工作
4. 推一些發展的更多變化，仍然作爲一個單一的承諾
5. 功能已準備好生產;合併專用生產分公司

再次基於工作流程：

在步驟2中，私有分支可能發展的最新頭重訂基期，前推。但是，如果這樣做，在步驟4重新綁定時會發生什麼？所有從第一次發行的變更（現在是發展的一部分）中的所有變化都將從新設立的私人分支中剝離出來，不是嗎？這會在生產中產生問題。

合併的工作流程：

在步驟2中，私有分支可以與最新的開發頭部合併;

• 合併提交可以在私有分支中丟棄，保持私有分支不受開發分支中發生的情況影響。但是這樣做，每次在開發過程中檢查某些內容時，都必須一次又一次地進行相同的合併。

• 可以保留合併提交，推動開發只需要合併自上次簽入以來的新增內容。但是當進行生產時，私人部門現在會從其他功能中進行更改。櫻桃採摘只能用於選擇相關的變更集，但這需要開發人員手動確定簽入的內容並容易出錯。

Answer 1

我會把每個功能放到它自己的分支（充分利用Git的輕量級分支）。一旦這個功能準備好了，master可以被合併到feature分支中，這個功能可以被驗證，然後這個分支可以被合併到master（或者製作，或者其他:)中）。

我在這裏使用的另一個補充是讓開發人員推送他們自己的遠程倉庫，然後讓1個負責人將開發人員遠程倉庫的變更從主存儲庫中移除。這有助於保持有福的倉庫的控制和「純潔」。