從集中式版本控制移轉至 Git

  • 發行項

將小組從集中式版本控制移轉至 Git，不只是學習新的命令。 為了支援分散式開發，Git 會以不同於集中式版本控制系統的方式儲存檔案歷程記錄和分支資訊。 規劃及實作從集中式版本控制系統成功移轉至 Git 需要了解這些基本差異。

Microsoft 已協助將許多內部小組和客戶從集中式版本控制系統移轉至 Git。 此體驗已根據一致成功的做法，產生下列指引。

成功移轉的步驟

若要成功移轉，小組應：

  • 評估目前的工具和程式。
  • 選取 Git 分支策略。
  • 決定是否以及如何移轉歷程記錄。
  • 維護舊版控制系統。
  • 從原始檔控制中移除二進位檔、可執行檔和工具。
  • 在 Git 概念和實務中訓練小組。
  • 測試移轉至 Git。

評估目前的工具和程式

變更版本控制系統自然會使用新的工具和做法來中斷開發工作流程。 這種中斷可能是改善 DevOps 程式其他層面的機會。

Teams 應該考慮在移轉至新系統時採用下列做法：

  • 持續整合 （CI），其中每個簽入 都會觸發組建和測試通過。 CI 有助於儘早識別缺陷，併為專案提供強大的安全網。

  • 簽入程式代碼之前的必要程式代碼檢閱 。 在 Git 分支模型中， 提取要求 程式代碼檢閱是開發程式的一部分。 程式代碼檢閱可補充 CI 工作流程。

  • 持續傳遞 （CD） 以自動化部署程式。 變更版本控制工具需要部署程序變更，因此移轉是採用新式發行管線的好時機。

選取 Git 分支策略

移轉程序代碼之前，小組應 選取分支策略。

在 Git 中，短期 的主題 分支可讓開發人員與主要分支密切合作，並快速整合，避免合併問題。 兩個常見的主題分支策略是 GitFlow 和更簡單的變化 GitHub Flow。

Git 不建議長期隔離的功能分支，這通常會延遲合併，直到整合變得困難為止。 藉由使用功能旗標等新式CD技術，小組可以快速將程式代碼整合到主要分支中，但仍會讓使用者隱藏進行中的功能，直到完成為止。

目前使用長期功能分支策略的 Teams 可以在移轉至 Git 之前採用功能旗標。 使用功能旗標可藉由將要移轉的分支數目降到最低，藉以簡化移轉。 無論他們使用的是功能分支或功能旗標，小組都應該記錄舊版分支與新 Git 分支之間的對應，讓每個人都了解認可新工作的位置。

決定是否要移轉歷程記錄

Teams 可能會想要將其現有的原始程式碼歷程記錄移轉至 Git。 數個工具宣告將所有分支的完整歷程記錄從集中式工具遷移至 Git。 Git 認可似乎相對會對應至舊版控制工具所使用的變更集或簽入模型。

不過，此對應有一些嚴重的限制。

  • 在大部分的集中式版本控制系統中，分支會以存放庫中的資料夾的形式存在。 例如，主要分支可能是名為 /trunk 的資料夾，而其他分支則為 /branch/one 和 /branch/two 等資料夾。 在 Git 存放庫中，分支包含整個存放庫，因此很難進行 1：1 的翻譯。

  • 在某些版本控制系統中，標籤或標籤是一個集合，可以包含樹狀結構中的各種檔案，甚至是不同版本的檔案。 在 Git 中，標記是特定時間點整個存放庫的快照集。 標記不能代表存放庫的子集，或合併不同版本的檔案。

  • 大部分的版本控制系統都會儲存檔案在版本之間變更方式的詳細數據，包括更細緻的變更類型，例如重新命名、取消刪除和復原。 Git 會將版本儲存為整個存放庫的快照集，以及檔案變更方式的元數據無法使用。

這些差異表示完整歷程記錄移轉最多會遺失，而且可能會產生誤導。 鑒於損失、涉及的工作，以及使用歷史的相對罕見，建議大多數小組避免匯入歷程記錄。 相反地，小組應該進行 小費移轉，只將最新分支版本的快照集帶入 Git。 對於大多數小組來說，時間最好花在具有較高投資報酬率的移轉區域上，例如改善流程。

維護舊版控制系統

在移轉期間和移轉之後，開發人員可能仍然需要存取舊版控制歷程記錄。 雖然舊版控制歷程記錄在一段時間內變得不那麼相關，但參考它仍然很重要。 高度管制的環境可能會有版本控制歷程記錄的特定法律和稽核需求。

特別是對於只執行小費移轉的小組而言，強烈建議無限期地維護先前的系統。 在移轉之後，將舊版控制系統設定為唯讀。

大型開發小組和受管制的環境可以將階層連結放在 Git 中，指向舊版控制系統。 簡單的範例是文本檔，在提示移轉之前，新增為 Git 存放庫根目錄的第一個認可，指向舊版本控制伺服器的 URL。 如果有許多分支移轉，則每個分支中的文本文件應該說明如何從舊系統移轉分支。 階層連結對於在移轉項目之後開始處理專案的開發人員也很有説明，而且不熟悉舊的版本控制系統。

拿掉二進位檔和工具

Git 的儲存模型已針對文本檔和原始程式碼的版本設定優化，這些檔案是精簡且高度可壓縮的。 二進位檔通常很大，一旦它們新增至存放庫，它們就會保留在存放庫歷程記錄中，並在每個未來的複製品中保留。 由於 Git 儲存歷程記錄的方式，開發人員應該避免將二進位檔新增至存放庫，尤其是經常變更的二進位檔。 移轉至 Git 是從程式代碼基底移除這些二進位檔的機會。

也建議從存放庫排除連結庫、工具和建置輸出。 請改用 NuGet 之類的套件管理系統來管理相依性。

圖示和圖稿等資產可能需要與特定版本的原始程式碼保持一致。 小型、不常變更的資產，例如圖示不會膨脹歷程記錄，而且您可以將它們直接包含在存放庫中。 若要儲存大型或經常變更的資產，請使用 Git 大型檔案 儲存體 （LFS） 擴充功能。 如需在 GitHub 中管理大型檔案的詳細資訊，請參閱 管理大型檔案。 如需 Azure Repos，請參閱 在 Git 中管理和儲存大型檔案。

提供訓練

移轉至 Git 的最大挑戰之一是協助開發人員瞭解 Git 儲存變更的方式，以及認可如何形成開發歷程記錄。 準備將舊命令對應至 Git 命令的速查表還不夠。 開發人員必須停止考慮集中式、線性模型，以及瞭解 Git 的歷程記錄模型和認可圖表方面的版本控制歷程記錄。

人員 以不同方式學習，因此您應該提供數種類型的訓練教材。 以實驗室為基礎的實時訓練與專家講師在一些人中運作良好。 Pro Git 書籍是一個很好的起點，可在在線免費取得。

可用的免費實際操作培訓班包括：

組織應努力識別小組的 Git 專家、協助其他人，並鼓勵其他小組成員提出問題。

測試移轉

一旦小組更新其程式、分析其程式代碼並訓練其成員之後，是時候移轉原始程式碼了。 無論您是進行小費移轉或移轉歷程記錄，請務必將一或多個測試移轉至測試存放庫。 在進行最終移轉之前，請確定：

  • 所有程式代碼檔案都會移轉。
  • 所有分支都可以使用。
  • 存放庫中沒有流浪二進位檔。
  • 使用者具有擷取和推送的適當許可權。
  • 組建成功，而且所有測試都會通過。

移轉程式代碼

在非工作時間進行最終移轉，在發生自然停機時，最好在里程碑之間執行。 在短期衝刺結束時移轉可能會導致問題，而開發人員正嘗試完成工作。 嘗試在週末移轉，當沒有人需要簽入時。

規劃公司從舊版控制系統完全移轉至 Git。 嘗試以平行方式操作多個系統表示開發人員可能不知道在哪裡或如何簽入。 將舊版控制系統設定為唯讀，以協助避免混淆。 如果沒有這項保護，可能需要包含過渡性變更的第二個移轉。

實際的移轉程式會根據您要移轉的系統而有所不同。 如需從 Team Foundation 版本控制 移轉的相關信息，請參閱從 TFVC 移轉至 Git。

移轉檢查清單

小組工作流程：

  • 判斷組建的執行方式。
  • 決定測試何時會執行。
  • 開發發行管理程式。
  • 將程式代碼檢閱移至提取要求。

分支策略：

  • 挑選 Git 分支策略。
  • 記錄分支策略、選取的原因，以及舊版分支對應的方式。

歷程記錄：

  • 決定保留舊版版本控制執行的時間長度。
  • 識別需要移轉的分支。
  • 如有需要，請建立階層連結，以協助工程師流覽回舊版系統。

二進位檔和工具：

  • 識別要從存放庫移除哪些二進位檔和不可變動的檔案。
  • 決定大型檔案的方法，例如 Git-LFS。
  • 決定傳遞工具和連結庫的方法，例如 NuGet。

定型：

  • 識別訓練教材。
  • 規劃訓練事件、書面材料及影片。
  • 識別小組成員，以擔任本機 Git 專家。

程式代碼移轉：

  • 執行多個測試回合，以確保移轉會順利進行。
  • 識別並傳達轉換時間。
  • 建立新的 Git 存放庫。
  • 將舊系統設定為唯讀。
  • 先移轉主要分支，然後移轉任何其他必要的分支。

下一步