本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
完整 CI/CD 程序有何不同
CI/CD 管道使用現代中繼線型工作流程，開發人員會將小型、頻繁的更新合併到透過 CI/CD 管道的 CD 部分建置和測試的主分支 （或中繼)。此工作流程已取代 Gitflow 工作流程，其中開發和發行分支以發行排程分隔。在許多組織中，Gitflow 仍然是熱門的版本控制和部署方法。不過，現在會被視為舊版，而且整合到 CI/CD 管道可能很困難。
對於許多組織而言，從 Gitflow 工作流程到以中繼線為基礎的工作流程的轉換尚未完成，結果是它們在過程中卡在某個位置，永遠不會完全遷移到 CI/CD。以某種方式來說，他們的管道最終會追蹤到舊版工作流程的特定遺體，並卡在過去和現在之間的過渡狀態。檢閱 Git 工作流程中的差異，然後了解使用舊版工作流程如何影響下列項目：
為了更輕鬆地識別現代組態中舊版 Git 工作流程的剩餘，讓我們比較 Gitflow 與現代、以中繼為基礎的方法。
Gitflow 方法
下圖顯示 Gitflow 工作流程。Gitflow 方法使用多個分支來同時追蹤多個不同版本的程式碼。您可以在開發人員仍在處理目前版本的程式碼時，將應用程式的更新版本安排在未來某個時間點。以主體為基礎的儲存庫可以使用特徵標記來完成此操作，但預設會內建於 Gitflow。
Gitflow 方法的一個結果是應用程式環境通常不同步。在標準 Gitflow 實作中，開發環境會反映程式碼的目前狀態，而生產前和生產環境仍會凍結在最新版本的程式碼基礎狀態上。
當瑕疵出現在生產環境中時，這會讓情況更為複雜，因為開發人員在未公開未發行的功能的情況下，無法將執行的程式碼基底合併到生產環境中。Gitflow 處理這種情況的方式是使用修正程式。從發行分支建立 Hotfix 分支，然後直接部署到上層環境。然後，Hotfix 分支會合併到開發分支中，以保持程式碼為最新狀態。
以中繼線為基礎的方法
下圖顯示以中繼線為基礎的工作流程。在以中繼為基礎的工作流程中，開發人員會在本機的特徵分支中建置和測試功能，然後將這些變更合併到主分支中。然後，主要分支會依序建置到開發環境、生產前環境和生產環境中。單元和整合測試會在每個環境之間進行。
使用此工作流程，所有環境都以相同的程式碼為基礎運作。不需要上層環境的 Hotfix 分支，因為您可以在主要分支中實作變更，而不會公開未發行的功能。主分支一律假設穩定、沒有瑕疵，並準備好發行。這可協助您將其整合為 CI/CD 管道的來源，其可透過管道中的所有環境自動測試和部署您的程式碼基礎。
