了解分支

8 分鐘

組建 Bicep 範本並在 Git 存放庫中工作時，小組的所有變更最終都會合併到存放庫的主分支。請務必保護主分支，避免將不必要的變更部署到您的實際執行環境。不過，您也希望參與者能夠彈性工作、與小組共同作業，並且輕鬆試用想法。

在本單元中，您會學習分支策略和保護主分支的方法。您也會學習如何為分支設定檢閱流程。

為什麼要保護主分支？

主分支是部署到 Azure 環境內容的真實來源。多數解決方案都會運用數種環境，例如開發、品質保證 (QA) 和實際執行環境。在其他情節中，您可能只有一種實際執行環境。無論使用多少環境，主分支都是小組成員參與的分支。成員的變更最後都會落在主分支。

典型的流程可能如下所示：

小組成員複製您的共用存放庫。
他們在自己的本機存放庫複本中，以本機方式對分支做出更動。
變更完成後，他們在本地存放庫的主分支中合併這些變更。
他們將這些變更推送至遠端存放庫的主分支。
在某些情節中，遠端存放庫的推送會觸發自動化管線來驗證、測試及部署程式碼。您會在其他 Microsoft Learn 課程模組中了解更多有關管線的資訊。

下圖說明此流程：

圖表顯示進行本地變更、將變更推送至遠端主分支，以及觸發管線的流程。

假設小組成員的變更引發細微的錯誤。完成流程執行之後，錯誤現在位於專案的主分支上並且部署到生產中。在嘗試部署並收到錯誤之前，您可能不會發現錯誤的存在。或者，針對其他型別的錯誤，部署可能會成功，但之後造成細微的問題。

在另一個情節中，假設小組成員正在處理功能，並將功能的一半成品推送至共用存放庫的主分支。現在您在主分支尚未完成或未經測試的內容上作出變更。這些變更不應該部署到您的實際執行環境。您可能需封鎖部署至實際執行環境的管道，直到功能完成為止。如果新完成的功能位於主分支上，您可能無法將之部署給您的客戶。

提示

對於大型小組來說，這些問題特別困難，其中多人參與相同的程式碼，但當您與多人共同作業時，本課程模組中的指導就相當有價值。即使您只有一人處理專案，並同時處理多項功能，本文的指導也很實用。

更好的方法，是在您進行變更時單獨處理。之後，您可以先請一位小組成員檢閱變更，再將變更合併到小組共用存放庫的主分支裡。這項流程有助小組先針對變更做出明智的決策，再由您核准並合併。

功能分支

「功能分支」是指您即將開始進行的新工作。工作內容可能是變更 Bicep 檔案中定義的資源設定，也可能是您需要部署的新資源集。每次開始新工作時，您都會建立新的功能分支。

您可以從主分支建立功能分支。在您建立分支時，您就能依目前的 Azure 環境狀態開始工作。您可以之後再進行所有需要的變更。

所有程式碼變更都會提交至功能分支，因此不會干擾存放庫的主分支。如果小組中有人需要對主分支進行緊急變更，則可在另一個與您無關的功能分支上執行。

您也可以在功能分支上共同作業。藉由將功能分支發佈並推送至共用存放庫，您和小組成員可以共同處理變更。您也可以在休假時將功能交由他人完成。

更新您的功能分支

處理功能分支時，可能會有其他功能合併至存放庫的主分支。結果就是功能分支和專案的主分支將會逐漸出現落差。兩個分支的落差越大，稍後再合併就會變的更加困難，遭遇的合併衝突也會越來越多。

您應該定期更新功能分支，以便納入對存放庫主分支所做的任何變更。開始將功能分支合併回主分支之前，最好也要先更新您的功能分支。這樣，您就知道自己能輕鬆將新的變更合併至主分支。

提示

經常將主分支合併到您的功能分支。

使用小型、短期的分支

盡量使用短期的功能分支。這種方法可藉由減少分支可能同步處理的時間長度，以協助您避免合併衝突。這種方法也可讓您的同事更輕鬆地了解您所做的變更，這在您需要某人檢閱變更時很有幫助。

將大型工作分割成較小的工作部分，並為每個工作建立功能分支。功能的規模越大，處理的時間就越長，功能分支的存留時間也越久。您可以在合併每個功能分支時，將較小的變更部署至實際執行環境，藉此逐漸建置更廣泛的工作內容。

試想您正對一組 Bicep 程式碼進行變更。您正要將一些資源定義移至模組。您也需要將一些新的資源新增至 Bicep 檔案。建議您先在各自的分支上執行所有模組重構。合併模組之後，您就可以接著處理 Bicep 檔案的新增項目。將變更內容分隔開來，有助維持每項變更及其分支的小型規模，使其易於理解。

使用這種方法作業時，不妨透過 if 關鍵字停用資源的部署，直到資源準備就緒。下列範例程式碼示範如何使用 if 關鍵字建立 Bicep 檔案來定義儲存體帳戶，但停用儲存體帳戶的部署，直到完成所有變更。

@description('Specifies whether the storage account is ready to be deployed.')
param storageAccountReady bool = false

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = if (storageAccountReady) {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Premium_LRS'
  }
}

您可以使用參數來為不同環境中的 storageAccountReady 變數指定不同的值。例如，您可以將測試環境的參數值設定為 true，並將實際執行環境的參數值設定為 false。這樣一來，您就能在測試環境中試用新的儲存體帳戶。

注意

當您在實際執行環境中啟用此功能時，請記得採取下列步驟，變更才會生效：

變更參數值。
重新部署您的 Bicep 檔案。

合併功能分支

處理完功能分支後，您必須將其合併到存放庫的主分支。請先檢閱功能分支上所做的變更，再進行合併。提取要求可讓您檢閱程式碼。您會在本課程模組的稍後部分了解提取要求。

分支保護

在 GitHub 中，您可以為共用存放庫的主分支設定分支保護。分支保護會強制執行規則，例如：

除了透過提取要求之外，無法將變更合併至主分支。
必須至少由兩位其他人員檢閱變更。

如果有人嘗試將提交直接推送至受保護的分支，推送就會失敗。您會在下一個單元中了解如何套用分支保護。

分支原則

在 Azure DevOps 中，您可以設定共用存放庫主分支的「分支原則」。分支原則會強制執行規則，例如：

除了透過提取要求之外，無法將變更合併至主分支。
必須至少由兩位其他人員檢閱變更。

如果有人嘗試將提交直接推送至受保護的分支，推送就會失敗。您會在下一個單元中了解如何套用分支原則。

其他分支策略

您可以在 Bicep 程式碼上共同作業時使用各種分支策略。每個分支策略都有優點與缺點。

您到目前為止學到的流程版本屬於「主幹型開發」策略。在此分支策略中，工作是在短期的功能分支上完成，然後合併成單一主分支。每次合併變更時，您可自動將共用存放庫主分支的內容部署到實際執行環境，或者您可能會根據排程 (例如每週) 批次變更並予以發行。主幹型開發淺顯易懂，且能共同作業而不會產生太多額外負荷。

有些小組會將已完成的工作與部署至實際執行環境的工作分開。他們會使用長期「開發」分支作為合併功能分支的目標。將變更發行至實際執行環境時，他們會將「開發」分支合併至其「主」分支。

其他分支策略需要您建立「發行分支」。若您有一組即將部署至實際執行環境的變更，則需建立包括要部署變更的發行分支。這些策略在定期部署 Azure 基礎結構，或與其他許多小組整合變更內容時相當實用。

其他分支策略包括 Gitflow、GitHub Flow 和 GitLab Flow。有的小組會用 GitHub Flow 或 GitLab Flow，因為這些策略可分隔不同小組的工作內容，並讓緊急錯誤修正與其他變更分開。這些流程也能將認可分隔至解決方案的不同發行，亦即「最佳決定選擇」。但這些流程需要更加密切管理，確保變更內容彼此相容。本課程模組的摘要提供這些分支策略的詳細資訊連結。

哪些分支策略適合您的小組，需視小組的工作、合作以及發行變更的方式而定。最好先從主幹型開發之類的簡單流程開始。如果您發現小組無法使用此流程有效運作，請逐漸引進其他的分支層級，或採用分支策略；但請注意，當您新增更多分支時，管理存放庫會變得更加複雜。

提示

不論您使用的分支策略為何，最好使用分支原則來保護主分支，並用提取要求檢閱變更。其他分支策略也會引進您應該保護的重要分支。

在本課程模組中，我們用主幹型開發處理功能分支，因為這項功能相對單純。