我正在使用TFS設置DevOps進程並想知道分支策略。如果我有以下樣本分支（圖片來自Guidance: A Branching strategy for Scrum Teams）。DevOps中的分支策略
我的DevOps處理建立與持續集成從主分支（具有詹金斯）（持續集成和連續遞送）。
請告知這個問題。
建議讓所有分支機構始終保持同步。當您想要處理修補程序時，可以從main創建一個新的分支「HotFix」。修補程序完成後，您需要將修補程序從HotFix合併到Main，並從Main合併到Release。
如果您在發佈中進行了任何更改，您需要合併到Main以完成更改。
修復程序是發佈軟件的修補程序。如果你有一個發佈分支，那麼創建一個修補分支是合適的。在將修補程序升級爲產品之後，您可以將產品鏈反向集成到Main中。修補程序 - >發佈 - >主要，甚至可以將它們整合到下一個sprint中，如果需要的話。
顯然，您選擇的答案取決於您的特定要求;但是，通常情況下，應該從主分區中釋放一個釋放，並從釋放分支中釋放一個熱修復。就我個人而言，我會說這些代碼不應該回到發佈分支，而是在開發分支中進行雙重修復。
這樣做的主要原因是，一旦你釋放了代碼，該代碼分支應該像發佈時一樣被鎖定。如果你遵循這一點，那麼你總是可以回到以前的事態。正如已經提出的那樣，當需求或優先級發生變化時，您可能會修改一個修補程序;或者當客戶報告實時代碼中的錯誤時。如果您維護一個單獨的分支，您可以隨時訪問該代碼。
通常，修補程序應從主分支上的相關版本中取出。 然後需要爲熱修復程序創建一個專用分支，將其與最後一個穩定分支合併。 如果它通過了整個QA，單元測試，系統測試等，然後將它合併回主分支作爲下一個發佈版本。
你可以看看下面的例子，當使用git的時候參考這裏：git best practice。源控制不是問題，而是主要想法。仔細閱讀文章，我相信你能找到你要找的東西。
還有一些組織仍在使用補丁... 我不是一個很有趣的解決方案，但如果這是你的情況，不要告訴我，因爲在補丁中有一點點不同的解決方案。
如果您使用的是敏捷，那麼功能分支可能是一個不錯的選擇。唯一的是它必須與JIRA或AGM等票務工具結合使用。爲了在這種情況下處理修補程序，您可以在AGM或JIRA中創建用戶故事，完成後將合併到主線主幹上。
爲什麼需要與其他產品關聯？ TFS在跟蹤工作項目方面做得很好。 –
我明白，這只是一個可能的例子。 –
如何處理這個問題真的取決於您的發佈和維護策略或客戶協議。
如果您的發佈分支也發生維護代碼行（看起來像您的描述），然後從它創建功能分支，實施熱修復，測試，合併回來併發布「修補程序」。理想情況下，您應該爲「維護」分支設置CI。 之後，您可以將熱修復與主代碼集成，或將積壓問題放在未來的新版本中以不同的方式實施。
BTW：一些不錯的文章在這裏： https://www.cmcrossroads.com/article/agile-perspective-branching-and-merging 和 http://www.bradapp.com/acme/branching/branch-creation.html
如果開發商往往合併到主會發生什麼？假設在sprint 2的中間，在prod中發現了一個bug，但是隨着開發的進展，開發人員幾次合併爲主sprint 2代碼。現在，構建從主分支開始，所以修補程序將進入主體以便構建和部署。您將如何使用DevOps處理這種情況？ – erdinger