每個bugfix的分離分支與dev分支的嫁接

我有3個環境 - dev，stage和production的應用程序。我有很多功能/錯誤修正必須獨立部署到舞臺和製作。每個bugfix的分離分支與dev分支的嫁接

的錯誤修正和功能通常有2/3的提交。

目前我使用水銀爲我的項目，但我不能決定哪個方向走。最好的應該是使用命名分支，但我不知道它是正確的1/2/3內提交。我發現移植物看起來也很有前景。

所以我的問題是如何版本的文件，如果我需要單獨能夠部署的變化？

2014-07-27 deem

您應該只從「主」或主分支部署到生產。每個錯誤修復/功能通常都是它自己的分支，以便您可以獨立驗證行爲而不影響主分支。一旦確定修復或功能完成，應該將其合併回主分支。從這個意義上說，您應該使用嫁接，其目的是從備用分支（即您的錯誤修復分支）中選擇接受的更改回到主分支進行部署。你不能在沒有分支的情況下使用嫁接，分支是測試對源代碼庫進行修改的最合適的方法，所以你不要用無意義或虛假的提交混亂主分支。您的主分支應該能夠隨時部署並仍然正常工作。

來源

2014-07-27 06:59:32 sfdcfox

這是也有可能有一個舞臺分支，並從開發移植到舞臺。 –

@SteveBarnes是的，我認爲是一樣的，但我不知道一個錯誤修復的分離分支將是一個更好的選擇。 – deem

@deem您可以從任何分支移植到任何其他分支。您的錯誤修正可以全部存在於他們自己的分支中，最終移植到分段，最後移植到主/主分支。保持每個錯誤修復或功能在其自己的分支上，可以讓您對分支進行不同的分析，以查看修復中涉及的文件/行，並且您可以輕鬆地僅從diff/patches中撤消某個分支。我現在工作的團隊現在只使用分支來標記發佈，但我認爲隔離修復將是更好的選擇。它可以讓你避開半固定的錯誤等。 – sfdcfox

您可以使用任何水銀分支模型（名爲|匿名分支機構，書籤，克隆） - 它的口味和習慣和任務的更多問題 - 與名爲分支，你就可以容易在未來的（如果|在需要時）檢測與每個完成的WIP作業相關的部分回購歷史記錄（僅僅因爲唯一的分支名稱是每個變更集中的永久性元數據，與匿名/共享相同的名稱與父/分支或書籤驅動/歷史記錄相反共同分支與其他變更/歷史分支混合）。

命名分支密集使用的單缺點是hg branches輸出長一段時間後。我更喜歡使用命名的分支，只是因爲它給的變化和更精緻的日誌可恢復歷史：而不是重複與嫁接變更的變化我看到一個合併的完成任務的庫顯示圖形的每一個積分都合併的目標

來源

2014-07-27 13:15:43

您知道在大約5k分支時可以有多大.hg /目錄嗎？我讀Mercurial可以處理甚至Nk分支，但它是否對克隆，合併，更新（最新變更集）命令有任何性能影響？看來git擁有更好的這種項目管理方式的架構。我還發現了類似http://www.plasticscm.com/features.aspx的東西，這些東西是專門爲任務開發設計的，每個功能/錯誤修正應該是一個分離的分支。 – deem

@deem - 不，我不知道大小。是的，一大批**分支機構可以並且將會影響整體績效，但經過數年的發展後，它將會非常顯着**，並且可以通過按年齡拆分知識庫來解決 –

每個bugfix的分離分支與dev分支的嫁接

回答

相關問題