假設有一個地方一個源代碼控制系統,當一個產品(在這種情況下安裝程序版本1)發佈。
發佈工程師將拍攝「發佈分支」狀態的快照,然後相應地爲下一個版本(本例中爲安裝程序版本2)重新命名。
開發人員將繼續在類似的分支(Dev分支)中編碼,該分支具有相同的位直到發佈日期。
從此「Release/Dev」分支中創建HotFixes/Patches分支,並從「熱修復或修補程序」分支中釋放修補程序。
這些補丁包含確定安裝前需求的邏輯。例如,「patch1-version1」需要「Release1版本」...「patch2-version1」需要的可能只是「patch1-version1」...等等。
當您準備創建第二版本「Release版本2「時,發佈分支將被相應地命名並且將具有」發佈版本1「+」所有修補程序「在」修補程序或修補程序「分支中的所有更改。
這個新版本需要邏輯來卸載以前的版本並安裝新版本。
現在,從最新的「Release Branch」創建一個新的「Hot Fixes」分支,或者將這些更改簡單地拖放到之前創建的「Hot Fixes」分支,以及任何用於「發行版本2 「現在應該更新了邏輯,只允許安裝新的需求......與」發佈版本2「有關的那些。
例如,「Patch1-ReleaseVersion2」將要求存在「Release Version2」...類似地,「Patch2-ReleaseVersion2」可能需要「發佈版本2」加上第一個發佈的補丁,或者只需要發佈第一個補丁,因爲基本版本(發佈版本2)也必須在那裏。
因此,根據此標準,「patch1,2,3 ... n-ReleaseVersion2」不應該安裝在任何具有「發行版本1」+零/更多修補程序的服務器上,因爲修補程序安裝程序中的邏輯不會(或不應該)允許這樣的事情。