標準分支計劃中的服務分支

Question

我對標準分支計劃有一個非常簡單的問題。

我明白分支，FI和RI等。我不太明白的是如何在實踐中使用Servicing分支。

我的理解是什麼時候發佈，我分支Main - > R1.SP1（假設這是我的第一個版本，例如），然後立即分支R1.SP1到R1。然後將R1設置爲只讀。這我完全理解和喜歡。

以下是我不明白的內容：R1.SP1，R1.SP2，R1.SP3如何以及何時創建？

我的RI SP1回到主界面，然後隨着時間的推移將主界面分支到SP2/3/n？

換句話說，這些未來的SP如何爲其自身的發佈/部署進行更改？

例如，如果客戶在R1中報告錯誤，我在哪裏檢查代碼以進行此更改，以及在哪裏簽入/提交更改/固定的代碼？我是否登記SP1分支？ （因爲R1分支是隻讀的）。那又怎麼樣？

我想我在問我的持續發展在哪裏，爲R1創建未來的SP，以及這些如何爲自己的發佈/部署創建和準備？

一個非常簡單的逐步場景例子將是最有幫助/讚賞。

請問，如果我的問題不清楚，請告訴我，我會盡我所能來修改它。

Answer 1

不是TFS專家，但我讀的是：

1. 開發者只需要檢查一次，在此基礎上推出車輛換作是（即修補程序進入產品HOTFIX分支）。
2. 不需要無基礎的合併。通過根據您的發佈車輛創建分層分支結構，創建自然合併路徑回到MAIN。
3. 降低迴歸風險。通過在MAIN->SP->和HOTFIX之間創建父/子分支關係，分支更改自然合併到未來版本中（即Hotfixes合併到分支中，以降低未來發行版中的缺陷迴歸風險）。

發佈分支創建後，從MAIN更改，您不應該合併（FI）到發佈分支。
更改應合併 - 從RELEASE到MAIN。
此外，改變應該總是通過中間分支合併（即RELEASE - >HOTFIX - >SERVICEPACK - >MAIN），以確保錯誤修復在後續版本保持一致。

我認爲，最後一節中明確提到合併的工作流程應該如何去一次一個版本已經發布到生產中。
它應該回到主體，直到已經合併足夠的水平以創建一組新船舶（從維修，您選擇一個版本開始您的新SPx，到Hoyfix.spx到release.spx）

---

的OP user1448758指出了評論，其中提到的文章Where do I fix a production defect?：

的Release分公司是hotfix或servicing分支的孩子，而不是在一個單獨的分支結構。 這允許您爲每個需要並行支持的小版本或主版本提供多個活動版本集（包含Service包，Hotfix,Release分支）。
此修復程序將應用於發現錯誤的特定發行版，然後將其合併到（RI）Main，並可能納入vNext開發分支。

由於開發分支vCurrent後vNext工作的工作被釋放，我鼓勵你固定在vNext發展分公司vCurrent（釋放後）發現的缺陷。
鬆開Sprint 1後，應固定在release側Sprint 1缺陷（釋放後），並在development側（vNext）修復衝刺2臭蟲（發行前）。

Release是hotfix一個孩子。 當您創建發行版時，hotfix和發行版的內容與相同。
Release是隻讀的，Hotfix可用於針對發佈的內容進行缺陷修復。

與反相結構中的問題，是你不能移動hotfix到Main不通過Release去，這樣做意味着你不再有代碼的副本發佈。