TFS Git 筆記 - 該用 TFVC 還是 Git？

SourceForge 式微，Codeplex 熄燈，時至今日，Github 算是在開源界一統江湖了，而 Git 也成為當今版控主流標準。

工作環境用的版控系統，汰換 VSS 後改用 TFS 多年，目前也遇上尷尬問題：該繼續用 TFVC(Team Foundation Version Control)，還是順應潮流移向 Git？

早期的 TFS 只支援 TFVC(就是 Check In/Check Out/Get Latest 那套傳統作法)， TFS 2013 起 起同時支援 TFVC 及 Git 兩種版控系統，而微軟在官方文件 - Choosing the right version control for your project 明白揭示，建議開發者以 Git 為主：

Git is the default version control provider for new projects. You should use Git for version control in your projects unless you have a specific need for centralized version control features in TFVC.  You can use TFVC repos with Git in the same Project so it's easy to add TFVC later if you need centralized version control. To setup a new repo type for an existing project use these instructions.

簡單來說：除非有非要集中式版控的理由，建議大家改用 Git 分散式版控，而新專案的預設值也會是 Git。

由 TFVC 換成 Git，勢必對開發人員帶來衝擊，以我自己的學習經驗，Git 不管概念或指令都比 TFVC 複雜，不是 GUI 摸索兩下就能上手，得下工夫。但就跟 WebForm、MVC 到 ASP.NET Core 的議題一樣，省下轉換學習成本但承擔與主流脫節風險，還是擁抱潮流接受改變但付出學習適應成本？ To be or not to be, that is the question.

讀了一些文章，整理二者差異優劣，作為決策參考：

• 4 Not-So-Obvious Reasons Why You Should Migrate From TFVC to Git
• Choosing the right version control for your project
• TFS vs. Git…or is it TFS with Git?
• Choosing Git Over TFVC In VSTS

TFS 從 2013 起支援 TFVC 及 Git 兩種版控做法：

• TFVC(Team Foundation Version Control) 使用單一集中化的伺服端儲存區追蹤及控制檔案版本，最新版內容永遠儲存在伺服器，開發者透過 Get Latest 取得最新版。
• Git 是一種分散式版控，使用每個開發者本機的儲存區追蹤及控制檔案版本，透過 Push 及 Pull 對遠端的共享伺服器送出或取回最新修改版本。

TFVC 與 Git 優缺點比較

Git 優劣點：(屬個人觀點，歡迎指正補充)

註：關於 Git，我之前有篇小抄，不足為學習教材，但可作為觀念與知識是否足夠的檢核依據。

1. 開發人員可將完整版控歷程複製到本機離線作業，修改告一段落再將結果同步至 TFS 伺服器。 不需要連線伺服器就能檢視歷史及比對版本差異，簽入修改也先在本機完成，稍後再同步回伺服器。除了可以離線作業的優勢，版控操作過程不需時時等待伺服器回應，輕巧快速非常多。
2. 由於本機擁有自己版控版本，可在本機隨意 Commit、Branch、Merge，要 Push 到伺服器前再整理，避免在版控主機上留下一堆雜亂記錄。 遇到問題時可任意退回上一版，反正只會發生在本機，不用擔心影響其他團隊成員。少了這層顧慮，在本機進行版控操作時更自由較無心理壓力。
3. 每個人的本機都有一份完整版控歷程，等同多了很多異機備援，即使伺服器毁損仍可用開發者的儲存庫還原。
   但缺點也在於每個人各有一份，歷程、版本可能存在差異，伺服器端記錄甚至可以被完全覆寫。(參考： 可怕的 git push -f )
4. Git 建立分支(Branch)的成本極低! 體會這點，可善用分支將修改切分成小單位，每個 Branch 只專注單一目標，如此讓提交內容的審核及合併單純化。 與 TFVC 相比，TFVC 切 Branch 需在本機複製整個 Solution 實體檔案(若包含 packages，常常數百 MB 起跳)，每個 Branch 一個資料夾，成本偏高手續較繁常讓人猶豫，我通常只有進行大幅改版才會考慮動用。
   ** 改用 Git 後，切記要差用 Branch，務必讓 TFVC 轉換 Git 投入的成本產生最大效益。但凡事過猶不及，狂開 Branch 很爽，Merge 時就苦了 **
5. Git 是業界標準，支援的平台眾多，專案如果想移至 Github、Bitbucket 或自建 Git Server，幾個指令就完成，不需費工夫轉換。
   採用 Git 可與其生態系統接軌，多了許多第三方 工具 可用，資源比 TFVC 豐富。
6. Git 技能比 TFVC 值錢，如果有機會換團隊、換公司，當別人問你會用 Git 嗎? 回答「略懂」多小能佔點便宜。

TFVC 優劣點：

1. 對於已使用 TFS 多年的開發人員，不需經歷轉換工具的學習及適應成本。但也潛藏與主流趨勢漸行漸遠的危機，端看如何取捨。
2. 版本採中央統一控管，簽出、簽入狀態的邏輯清晰，彼此程式碼版本衝突的狀況較少。
   相較之下，Git 核心精神採分散管理，各自開發，透過 Pull Request 方式合併，合併時需要更多人為檢視處理。 從管理層面來看，多了人為把關有助於提升程式碼品質，但對較簡單的專案來說增加了管理負擔。
3. 每個開發者的本機只需保留最新版, 不像 Git 會在每台電腦保留一份完整儲存區，可節省儲存空間及首次 Clone 時的傳輸時間。 我遇到的極端例子內含大量 PDF、圖檔、影音檔的網站專案，本機儲存區大到令人咋舌。
   (註：集中成伺服器一份有優點，但也失去在每台機器保留異地備援版控記錄的額外好處)
4. TFVC 採中央統一控管，只有簽入、簽出、取得最新版、檢視歷史就能打通關，動作單純用 GUI 就能輕鬆搞定。 Git 需要較多指令操作，觀念不同複雜度也較高，GUI 介面 (Visual Studio 不足之處要靠第三方軟體如 SourceTree 補位)無法涵蓋所有情境，友善度不如 TFVC。

動作對照

TFVC 與 Git 動作對照表： 參考來源

TFVC 使用者改用 Git 時，掌握以下要點會更得心應手：

• Check-In 動作在 Git 拆成兩段：Commit 是把修改存入本機版控，Push 到伺服器別人才會看到
• 用 Pull 可取回伺服器上的最新版，下一步可 Branch 一份修改，中間可以反覆 Commit
• Git 的 Branch 成本極低，不像 TFVC 開一個 Branch 要複製整個資料夾，顅忌少很多
• 在本機改壞可隨時 Revert 回上一 Commit，甚至放棄另外 Branch 一份重新開始也成，因為一切都發生在本機，不會被別人看到也不會影響別人
• 對修改滿意了，將 Branch Merge 回主版本，再 Push 回伺服器(若歷程太亂，可先 Rebase 整理再上傳伺服器)

結語

Git 是當今版控主流標準，微軟也講明 Git 已是 TFS 專案預設選項，除非有特殊考量才用 TFVC。是否要從 TFVC 轉成 Git？(或者說，是否該繼續用 TFVC？)，答案不語而喻。但回歸實務面如何抉擇，說穿了是兩股力量的拉扯：

拉力來自擁抱主流享受資源及維持競爭力的心態，阻力則是轉換版控系統的衝擊及學習適應成本考量。

平心而論，Git 的學習曲線挺陡峭，不宜低估轉換成本，這點讓抉擇格外困難。而我試著用 WebForm 比擬來簡化：

從 WebForm 轉到 MVC，甚至 ASP.NET Core 絕不是輕鬆事，若堅持不想花太多時間學 JavaScript，則還有 Web Pages / Blazor Pages 等選項， 但不管轉換成哪一種，都少不了學習成本，得付出時間心力作為代價。

此時此刻，可以選擇現在開始投資，或是能撐多久算多久。無論選擇何者，生命會自己找出路，地球會繼續轉，工作與生活都能繼續下去... 只是，如果你選擇按兵不動，有空記得想想困在浮冰的北極熊。

(北極熊好忙之「暗! 三天兩頭就 Cue 我是怎樣?」)

Evaluation of TFVC and Git when using TFS 2013+.