我們的SCM是Subversion。我不知道如何處理這種情況。如果您的質量保證環境中正在測試的功能延遲發佈，該怎麼辦？
比方說，我有這些分支：
在我們有以下的特點（F）主幹：
F1和F2已經準備好要在QA環境測試，因此對應於這些功能將更改合併到QA分支。 QA：
但如果管理者希望釋放F1，因爲QA已經完成了F1要求testings但是這不是對F2的情況。
這意味着我只需要將對應於F1的更改合併到PRODUCTION分支中，但這也意味着此新結果將與QA人已經測試的結果不同，這是因爲PRODUCTION分支只會有F1要求。我不能保證它會起作用，並且這個新的合併代碼在沒有經過測試的情況下投入生產是錯誤的。
這將導致例如不同的問題： - 如果有某種F1和F2之間的依賴關係（他們不應該對自己發佈） 什麼 - 你永遠不會知道，如果新代碼將工作，因爲沒有一個環境來測試這個新的合併代碼。
你會如何解決這個問題？
謝謝你，對不起我的英文。
您可以推薦在QA分支上建立一個快速生成周期。回滾不需要的更改（或者合併回QA分支上的早期版本，或者爲QA創建一個新分支，並僅將F1更改合併到新的QA分支中） - 基本上推薦一個快速構建和完整性測試周期，代碼被髮布到生產中。強調將未經測試的代碼發佈到LIVE場景中的風險。
從長遠來看，它可能還清設置CI以幫助持續集成和測試 - 這將有助於至少獲得給定分支上的代碼 - 測試整個測試以用於任何功能組合你選擇檢查分支。
Goodluck。
但是如果管理者想要發佈F1，因爲QA已經完成了F1需求的測試，但F2的情況並非如此？
這就是管理者的特權。他們可以決定只發布F1。
您的責任是說F1在質量保證環境中未經過正確測試。你在你的問題中給出了原因。
這意味着我必須只將與F1相對應的更改合併到PRODUCTION分支中，但這也意味着此新結果將與QA人已經測試的結果不同，這是因爲PRODUCTION分支將只有F1的要求。我不能保證它會起作用，並且這個新的合併代碼在沒有經過測試的情況下投入生產是錯誤的。
你是對的。同樣，你的責任是說F1在質量保證環境中沒有被單獨測試過。
一般來說，使用單獨的分支進行開發，質量保證和生產並不容易管理，正是由於您所描述的情況。基本上，由於您不能相信QA和PRODUCTION分支是相同的，因此您必須在合併QA分支後，在PRODUCTION分支上運行完整的測試過程。那麼有獨立的分支有什麼好處呢？
Subversion Book有一篇關於Common Branching Patterns的文章，建議使用功能分支（QA可以直接測試），並在準備發佈時合併到主幹中;它建議的另一個選擇是有一個樹幹，它被分支到釋放分支，在釋放之前或之後可以修復錯誤。
您可以通過使用feature flags來更好地控制哪些功能可以發佈，您可以做的一件事 - 這允許QA並行測試F1和F2，併發布準備就緒的任何一個。