採用 Git 分支策略

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Git 等分散式版本控制系統可讓您彈性地使用版本控制來共用和管理程式碼。 您的小組應該在此彈性與需要以一致的方式共同作業和共用程式代碼之間找到平衡點。

小組成員會透過與其他人共用的 Git 分支，發佈、共用、檢閱和逐一查看程式代碼變更。 為您的小組採用分支策略。 您可以更妥善地共同作業，並花更少的時間管理版本控制，以及更多開發程式代碼的時間。

下列分支策略是以我們在 Microsoft 使用 Git 的方式為基礎。 如需詳細資訊，請參閱 如何在 Microsoft 中使用 Git。

讓您的分支策略保持簡單

讓您的分支策略保持簡單。 從下列三個概念建置您的策略：

• 所有新功能和 Bug 修正均需使用功能分支。
• 使用提取要求將功能分支合併至主要分支。
• 保持高品質的最新主要分支。

擴充這些概念並避免矛盾的策略，會導致小組的版本控制工作流程一致且容易遵循。

為您的工作使用功能分支

開發您的功能，並根據主要分支修正功能分支中的 Bug。 這些分支也稱為 主題分支。 功能分支會將進行中的工作與主要分支中已完成的工作隔離。 建立和維護 Git 分支成本低廉。 即使是小型修正和變更也應該有自己的功能分支。

為所有變更建立功能分支，讓檢閱歷程記錄變得簡單。 查看分支中所做的認可，並查看合併分支的提取要求。

依慣例為您的功能分支命名

針對功能分支使用一致的命名慣例，以識別在分支中完成的工作。 您也可以在分支名稱中包含其他資訊，例如建立分支的人員。

命名功能分支的一些建議：

• users/username/description
• users/username/workitem
• bugfix/description
• feature/feature-name
• feature/feature-area/feature-name
• Hotfix/描述

注意

如需設定原則以強制執行分支命名策略的資訊，請參閱 要求分支資料夾。

使用功能旗標來管理長時間執行的分支

深入瞭解如何在 程序代碼中使用功能旗標 。

使用提取要求檢閱和合併程序代碼

提取要求中發生的檢閱對於改善程式代碼質量至關重要。 只有透過傳遞檢閱程式的提取要求來合併分支。 避免將分支合併至主要分支，而不需提取要求。

提取要求中的檢閱需要時間才能完成。 您的小組應該同意提取要求建立者和檢閱者的預期。 散發檢閱者的責任，以在小組中分享想法，並散佈程式代碼基底的知識。

成功提取要求的一些建議：

• 兩位檢閱者是根據研究的最佳數位。
• 如果您的小組已經有程式代碼檢閱程式，請將提取要求帶入您已執行的動作。
• 請小心將相同的檢閱者指派給大量的提取要求。 當檢閱者責任在整個小組中共用時，提取要求的運作效果更好。
• 在描述中提供足夠的詳細數據，讓檢閱者快速加快變更的速度。
• 使用提取要求，包含在分段環境中執行的變更組建或連結版本。 其他人可以輕鬆地測試變更。

保持高品質、最新的主要分支

主要分支中的程式代碼應該通過測試、清楚建置，且一律為最新狀態。 您的主要分支需要這些品質，讓小組建立的功能分支從已知的良好程序代碼版本開始。

為您的主要分支設定 分支 原則，以便：

• 需要提取要求才能合併程序代碼。 此方法可防止直接推送至main分支，並確保討論建議的變更。
• 建立提取要求時自動新增檢閱者。 新增的小組成員會檢閱程序代碼，並批註提取要求中的變更。
• 需要成功的組建才能完成提取要求。 合併至主要分支的程式代碼應該會完全建置。

提示

提取要求的建置管線應該會快速完成，因此不會干擾檢閱程式。

管理版本

使用發行分支來協調和穩定程式碼版本中的變更。 此分支存留時間很長，而且不會合併回提取要求中的主要分支，與功能分支不同。 視需要建立多個發行分支。 請記住，每個作用中版本分支都代表您需要支援的另一個程式代碼版本。 當您準備好停止支援特定版本時，請鎖定發行分支。

使用發行分支

當您接近發行或其他里程碑時，請從main分支建立發行分支，例如短期衝刺結尾。 為這個分支指定與發行相關聯的清楚名稱，例如 release/20。

建立分支以修正發行分支中的 Bug，並將其合併回提取要求中的發行分支。

埠變更回主要分支

請確定修正程式同時位於您的發行分支和主要分支中。 其中一種方法是在發行分支中進行修正，然後將變更帶入您的主要分支，以防止程式代碼中的回歸。 另一種方法（以及 Azure DevOps 小組採用的方法）是一律在 mainline 中進行變更，然後將那些變更移植到發行分支。 您可以深入瞭解我們的 發行流程 策略。

在本主題中，我們將討論在發行分支中進行變更，並將其移植到主線。 使用櫻桃挑選，而不是合併，以便您完全控制哪些認可會移植回 main 分支。 將發行分支合併到main分支可以帶來您在主要分支中不想要的發行特定變更。

使用下列步驟在發行分支中所做的變更來更新 main 分支：

1. 從主要分支建立新的功能分支，以移植變更。
2. 從發行分支挑選變更到您的新功能分支。
3. 在第二個提取要求中，將功能分支合併回 main 分支。

此發行分支工作流程會保留基本工作流程的支柱：功能分支、提取要求，以及一律具有最新版程式代碼的強主要分支。

為何不針對版本使用標籤？

其他分支工作流程會使用 Git 標籤 將特定認可標示為發行。 標記對於將歷程記錄中的點標示為重要很有用。 卷標會在您的工作流程中引進額外的步驟，如果您針對發行使用分支，則不需要這些步驟。

標記會與認可分開維護及推送。 小組成員可以輕鬆地錯過標記認可，然後之後必須返回歷程記錄以修正標記。 您也可以忘記推送標記的額外步驟，讓下一個開發人員在支援版本時，從舊版的程式代碼中工作。

發行分支策略會擴充基本功能分支工作流程來處理發行。 您的小組不需要採用任何新的版本控制程式，而不是櫻桃選擇來移植變更。

管理部署

您可以使用處理多個版本的相同方式來處理程式碼的多個部署。 建立明確的命名慣例，例如 部署/效能測試，並像發行分支一樣處理環境分支。 您的小組應同意使用主要分支的程式來更新部署分支的程式。 部署分支中的櫻桃挑選錯誤修正回到主要分支。 使用與從發行分支移植變更相同的步驟。

這項建議的例外狀況是，如果您使用持續部署的形式。 使用持續部署時，請使用 Azure Pipelines ，將組建從主要分支升級為部署目標。