將團隊從集中式版本控制遷移到 Git 需要的不僅僅是學習新命令。 為了支援分散式開發，Git 儲存檔案歷史記錄和分支資訊的方式與集中式版本控制系統不同。 規劃和實施從集中式版本控制系統成功遷移到 Git 需要了解這些基本差異。
Microsoft 已協助將許多內部小組和客戶從集中式版本控制系統移轉至 Git。 這種經驗根據始終成功的實踐產生了以下指導。
成功移轉的步驟
為了成功遷移，團隊應該：
- 評估當前的工具和流程。
- 選取 Git 分支策略。
- 決定是否以及如何移轉歷程記錄。
- 維護先前的版本控制系統。
- 從原始檔控制中移除二進位檔、可執行檔和工具。
- 訓練小組的 Git 概念和做法。
- 測試移轉至 Git。
評估目前的工具和流程
更改版本控制系統自然會破壞新工具和實踐的開發工作流程。 這種中斷可能是改進 DevOps 流程其他方面的機會。
小組在移轉至新系統時，應考慮採用下列做法：
持續整合 （CI），其中每次簽入都會 觸發建置和測試通過。 CI 有助於及早發現缺陷，並為專案提供強大的安全網。
簽入程式碼之前必須進行程式碼檢閱。 在 Git 分支模型中， 拉取請求 程式碼審查是開發流程的一部分。 程式碼檢閱補充了 CI 工作流程。
持續交付 （CD） 可自動化部署程序。 變更版本控制工具需要變更部署程式，因此移轉是採用新式發行管線的好時機。
選取 Git 分支策略
在移轉程式碼之前，小組應該 選取分支策略。
在 Git 中，短期 主題分支允許開發人員紧密结合主分支並快速集成，避免合併問題。 兩種常見的主題分支策略是 GitFlow 和更簡單的變體 GitHub Flow。
Git 不鼓勵長期、孤立的功能分支，這些分支往往會延遲合併，直到整合變得困難。 透過使用 功能旗標等現代 CD 技術，團隊可以快速將程式碼整合到主分支中，但仍會對使用者隱藏進行中的功能，直到它們完成為止。
目前使用長期功能分支策略的小組可以在移轉至 Git 之前採用功能旗標。 使用功能旗標可將要移轉的分支數目降到最低，以簡化移轉。 無論使用功能分支還是功能旗標，團隊都應該記錄舊分支和新 Git 分支之間的對應，以便每個人都了解在何處提交新工作。
決定是否要移轉歷程記錄
團隊可能會想將其現有的原始程式碼歷史記錄遷移到 Git。 一些工具聲稱可以將所有分支的完整歷史記錄從集中式工具遷移到 Git。 Git commit 似乎能夠相對順利地對應到舊版控制工具使用的變更集或簽入模型。
然而，這種映射有一些嚴重的限制。
在大多數集中式版本控制系統中，分支以資料夾的形式存在於存放庫中。 例如，主分支可能是名為 /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 的學習路徑簡介。
- 開始 使用 Azure Repos 中的 Git 快速入門。
- GitHub 的 Git 和 GitHub 學習資源。
組織應該努力識別團隊中的 Git 專家，賦予他們幫助他人的能力，並鼓勵其他團隊成員向他們提問。
測試移轉
一旦團隊更新了他們的流程、分析了他們的程式碼並培訓了他們的成員，就該遷移原始程式碼了。 無論您是進行提示遷移還是遷移歷史記錄，都必須將一或多個測試遷移到測試儲存庫中。 在進行最終移轉之前，請確定：
- 所有程式碼檔案都移轉。
- 所有分店均正常營運。
- 儲存庫中沒有雜散二進位檔。
- 使用者具有適當的權限來擷取和推送。
- 建置成功，且所有測試都通過。
移轉程式碼
在非工作時間進行最終移轉，最好是在有自然停機時間的里程碑之間進行。 在短期衝刺結束時進行遷移可能會在開發人員嘗試完成工作時造成問題。 嘗試在沒有人需要簽到的周末遷移。
規劃從舊版本控制系統到 Git 的確定切換。 嘗試平行操作多個系統意味著開發人員可能不知道在何處或如何簽入。 將舊版本控制系統設定為唯讀，以協助避免混淆。 如果沒有此保護措施，可能需要包含臨時變更的第二次移轉。
實際移轉程序會因您要移轉的系統而異。 如需從 Team Foundation 版本控制移轉的相關資訊，請參閱 從 TFVC 移轉至 Git。
移轉檢查清單
團隊工作流程：
- 決定組建的執行方式。
- 決定何時執行測試。
- 開發發布管理流程。
- 將程式碼檢閱移至提取要求。
分支策略：
- 選擇 Git 分支策略。
- 記錄分支策略、選擇該策略的原因，以及舊分支的映射方式。
History:
- 決定讓舊版版本控制持續執行多長時間。
- 識別需要移轉的分支。
- 如有需要，請建立麵包屑導航，以協助工程師返回舊版系統。
二進位檔和工具：
- 識別要從存放庫中移除哪些二進位檔和不可差異的檔案。
- 決定大型檔案的方案，例如 Git-LFS。
- 決定傳遞工具和程式庫的方法，例如 NuGet。
訓練：
- 確定培訓材料。
- 規劃培訓活動、書面材料和影片。
- 確定團隊成員擔任本地 Git 專家。
程式碼遷移：
- 執行多次測試執行，以確保移轉順利進行。
- 識別並傳達切換時間。
- 建立新的 Git 存放庫。
- 將舊系統設定為唯讀。
- 先移轉主要分支，然後移轉任何其他需要的分支。