gitflow為什么我們需要掌握

Question

在gitflow中，所有發布分支最終都是

1. 合並為主人
2. 合並發展
3. 標簽大師
4. 刪除發布分支

但為什么我們不這樣做

1. 標記發布分支
2. 合並發展
3. 刪除發布分支

如果是修補程序，我們可以

1. 最新標簽的分支
2. 做修補程序
3. 標記熱修復分支
4. 合並發展
5. 刪除修補程序分支

Answer 1

讓我試着把我的理解放在這里，

git分支命名約定master, develop & release被很好地定義並被采用來與普遍同步。 這並不意味着您需要遵循，您可以定義您的願望並推送給您的客戶和用戶。許多組織遵循通用命名約定以避免不必要的混淆。

在mercurial中，Many跟隨分支命名default而不是master 。

定義在一行：

master  : Ready Product (Public Available)

develop : Requirements/bugs/Improvements Implementation In Progress (Not recommended to use)

release : Preparing to `Ready Product` (Private or internal)

tag master : Stable Product with defined features.

您可以參考This This This獲取更多信息

Answer 2

對於gitflow中需要master分支（ develop分支不能替換）的主要原因：

• master分支上的所有版本都應該足夠穩定，因為它用於產品環境。
• 而對於develop分支機構，即使沒有驗證，所有開發人員也可以直接推動他們的工作。 這意味着， develop分支可能會“臟”，這將導致生產/生活環境崩潰。

Answer 3

您幾乎描述了一個發布流分支模型：

• 開發人員與公共主線分支合並（稱之為開發或主控）
• 當你准備從主線發布分支（稱之為發布/ r-1.2等）
• 當您發現新版本的問題時創建一個修補程序分支（修補程序/修復程序）
• 像往常一樣，將修補程序合並到主線中
• Merge / cherry將修補程序添加到您的發布分支中
• 發布分支表示將其部署到該環境時的生產

生產分支沒有最終合並 - 因為發布分支是相同的，所以不需要它。

一旦舊版本分支被下一個分支取代，如果不再需要用於審計目的，則可以將其刪除。

VSTS團隊記錄了這一點： https ： //docs.microsoft.com/en-gb/azure/devops/devops-at-microsoft/release-flow