版本控制系統的選擇

Git 和 Mercurial

請參閱 Git 的網站和 Mercurial 的網站

多年來，Git 和 Mercurial 一直是流行的分散式版本控制系統技術。尤其像 GitHub 這樣的平台使 Git 成為 SCM、SVC 或原始碼版本控制的預設選擇。雖然 Linux 核心是用 Git 維護的，並且肯定利用了 Git 的分散式版本控制系統特性（即許多不同的核心版本可以長期存在），但大多數企業仍然會將單個程式碼版本庫視為主要程式碼版本庫，並將其中的單一個分支作為長期「最有價值」的程式碼開發路線。

在 Git 程式碼版本庫中進行主幹開發是完全可能的。按照慣例，「main」是長期最有價值的分支，一旦 clone 到本地的個人電腦，該版本庫就會獲得「origin」的暱稱。

Fork

對於 Git 來說，有效的主幹開發策略取決於開發者維護 origin 的一個分叉（以及其中的 main 分支），並且拉取請求是提交的程式碼在被合併進入 origin:main 之前進行審查的地方。其他分支模型也使用相同的拉取請求流程進行程式碼審查——這是自 GitHub 推出該功能以來，使用 Git 的正常工作方式。

大小限制

從歷史上看，Git 和 Mercurial 並不擅長維護大於 1GB 的壓縮歷史記錄大小。許多團隊報告說他們的程式碼版本庫大小超過了這個限制，因此意見不一。快速達到 1GB 上限的一種方法是使用更大的二進位檔。由於 Git 將歷史記錄保存在壓縮程式碼版本庫中，因此即使是一個經常更改的較大型二進位檔也可以將總使用量推高到 1GB 以上。

但是，通過正確地為 Git 配置 Git-LFS 擴充之類的方法，可以避免或延遲很多年才會達到 1GB 的限制。

在 Git 程式碼版本庫中限制較大 cloning 大小的其他方法包括建議使用 --shallow-since 參數指定部分 cloning 日期範圍，或者使用 Git 最新的 Partial-Clone 功能，例如GitLab 支援獲取 Git 提交歷史記錄，而無需獲取所有 blob，而是讓 blob 按需透明地下載。

Git 還具有 submodule 和 subtree ，以允許在一個可 clone 的集合中進行大型模塊聯合。對於他們的 Android 計劃，Google 也製作了 Git-repo。

根級分支

稍後我們會清楚地看到為什麼我們提到這一點，但 Git 和 Mercurial 維護來自 checkout clone 的根資料夾的分支，並為使用者維護有關分支與程式碼版本庫讀寫的單一許可權。

未來發展

有一種說法是，Mercurial 正在接受貢獻，這將使它能夠進入 Google 等公司需要的程式碼版本庫領域。

Git 和 Mercurial 沒有分支或目錄許可權，但使用它們的一些平台會新增分支權限。

Linus Torvalds 向 Google 員工展示 Git

早在 2007 年，Linus Torvalds 就在 Google 的山景城辦公室向 Google 員工展示了他受 Bitkeeper 啟發的 Git

他兩年前就開始製作它，現在是版本控制系統的首選。在這一點上，Google 已經運行了主幹開發風格幾年了，並且沒有後悔。一些 Google 員工後來擴展了他們的 Perforce（見下文）設置，以允許開發者個人電腦上的本地分支進行 Git 操作。

平台軟體選擇

GitHub - Git、雲端
GitHub Enterprise - GitHub 本地版中的 Git
GitLab - Git、雲端和本地安裝
Atlassian 的 Bitbucket - Git
RhodeCode - Git、Mercurial 和 Subversion
Assembla - Git、Mercurial、Perforce 和 Subversion
適用於 Git 的各種 Collabnet 產品和服務
Microsoft 的 Visual Studio Team Services - Git、雲端
Microsoft 的 Team Foundation Server - Microsoft 本地版中的 Git

Perforce

Perforce 的網站

Vanilla Perforce

Perforce 是一個閉源的工業級版本控制系統。Pixar 將製作電影所需的一切儲存在其中，而 Adidas 則將所有設計儲存在其中。直到 2012 年，Google 都在使用它的主幹，以及數十 TB 的歷史記錄。隨著使用量的增加，他們轉向內部解決方案。Perforce 的獨特之處在於它的「p4d」（單個伺服器端可執行二進位檔）是整個伺服器，不需要安裝 - 只需執行即可。

Perforce 是最後一個通常在開發者個人電腦上維護唯讀位的版本控制系統技術。你絕對需要為你的整合式開發環境安裝外掛來處理與服務器的通訊操作，以便你不會遇到源文件為唯讀的情況。由於 Perforce（p4）客戶端必須涉及與服務器互動來改變編輯源文件的唯讀位，因此它需要與伺服器建立永久連接。這有助於提高用戶端上非常大的檔集的操作速度。Perforce 服務器已經知道哪些文件需要在你的工作副本中進行更新，而不需要你執行「p4 sync」操作。這樣可以避免需要遍歷目錄以尋找本地更改的文件，並且意味著同步操作可以限制在一秒鐘左右。

從歷史上看，Perforce 無法在本地顯示其中檔的歷史記錄。它需要再次建立伺服器連接才能執行歷史記錄操作。不過，較新版本的 Perforce（見下文）中的許多分散式版本控制系統功能現在允許本地歷史記錄。

Perforce 允許在任何子目錄中設置分支，而不僅僅是根目錄。它還允許在大型和小型原始程式碼樹中的任何目錄（或分支）中指定讀取或寫入權限。

無需程式碼審查

Perforce 傳統的伺服器常駐程式並未整合程式碼審查功能。通過自定義修改的 GitLab，稱為 GitSwarm 的外掛，Perforce 現在具有了程式碼審查能力。它也可以透過稱為 Swarm 的外掛（一個稍舊的產品），該產品不提供 GitSwarm 的 Git 功能，但卻新增了許多團隊軟體功能，如程式碼審查。

Git Fusion

Perforce 公司提供了一個虛擬機器應用程式，可以放置在你的基礎設施中，並在純淨的 Perforce 伺服器與你在開發個人電腦上使用純 Git 工作流程之間進行調解。

使用來自 Perforce 程式碼版本庫的 Git Fusion clone 並指定了客戶端規範，你可以獲得原始程式碼樹的子集表示形式，並附有歷史記錄。這是一個簡潔的功能。通過 Git Fusion checked 的內容也不受唯讀位特性的限制。

GitSwarm 有點取代它。

p4-git and p4-dvcs

P4-git 與 Git Fusion 技術非常相似，但不是由 Perforce 人自己製作的。它也不需要啟動第二個伺服器設備（就像 Git Fusion 一樣）。

2015年，Perforce技術擴展到包括自定義分散式版本控制系統功能。p4-git 的所有功能，但沒有 Git 相容性。

至於 Git Fusion，通過 p4-git 和 p4-dvcs checked 的內容不受 p4d 的唯讀位控制的阻礙。

Subversion

Subversion 的網站

Subversion（Svn）已經開發了 16 年，是協作版本系統急需的開源替代品。它追逐 Perforce 的一些功能，但開發速度相當緩慢。沒有人將 Subversion 推向 Perforce 的使用水準，但聲稱這是一種可能性。

Subversion 和 Perforce 一樣，具有對目錄和分支的讀寫許可權。

有趣的是，有一個「Subversion vs Git」網站試圖反駁一些廣泛持有的社群對 Subversion 的看法，以及它如何與 Git 相提並論。

還要注意的是，Subversion 團隊本身並不進行基於主幹的開發，儘管 Subversion 為新建立的程式碼版本庫提供了預設的根目錄 trunk、tags 和 branches。

無需程式碼審查

請注意，Subversion 沒有本地分支功能，要進行程式碼審查，你需要在它旁邊安裝第三方伺服器。或者，更好的選擇是使用整合程式碼審查的平台，如下所示。

Git-Svn

有一個 Git 的擴展可以讓它處理 Subversion 的後端。一個 Git-subversion 的複本擁有所有 Git 的本地歷史、本地分支的可能性。這種操作模式所提供的本地分支可能性非常方便，它應該可以輕鬆地與你安裝的任何 Svn 主機平台一起使用。

註：從 Subversion 複製的 clone 版本可能比從 Git 複製的相等版本慢許多倍，因為它在客戶端重新建立了壓縮的 Git 歷史，就像使用經典的 Subversion 線路協定一樣，這更加冗長。實際上，對於一個規模合理的團隊多年的提交，初始 clone 可能需要花費許多小時。

平台軟體選擇

RhodeCode - 可本地安裝
Various Collabnet 產品和服務
ProjectLocker - 雲端
Deveo - 雲端
RiouxSvn - 雲端
SilkSvn - 雲端
Assembla - 雲端和可本地安裝 on-premises
XP-dev - 雲端
Codeplex - 雲端

Team Foundation Server - TFS

TFS 的網站

Microsoft 於 2000 年代中期推出了 TFS，採用了一種自定義的版本控制系統技術「TFVC」。據說他們在九十年代開發了一個內部工具「SourceDepot」，這是一個特殊版本的 Perforce，而 TFS 反映了那個技術的一些工作方式。它已發展成為一個多面向的伺服器平台。也許甚至是企業整個應用生命週期管理需求的一站式解決方案。最近，Microsoft 在 TFS 中鼓勵使用 Git，而不是他們最初開發的專有版本控制系統。

TFS 與基於主幹的開發使用方式完全兼容。

註：Microsoft 正在向 Git 社群捐贈 Git 虛擬文件系統，它允許 Git 的某些單一版本庫使用。

PlasticSCM

Plastic 的網站

PlasticSCM 是一個現代的分散式版本控制系統，類似於 Git 和 Mercurial，但都是閉源的。它與基於主幹的開發相容，並且非常獨立（整合了程式碼審查等）。Plastic 非常適合處理更大的二進位檔，並帶有直觀的「分支瀏覽器」，可以查看分支的演變、查看差異、執行合併等。對於單個程式碼版本庫的大小，數 TB 並非聞所未聞。至少對於一些遊戲行業的客戶來說。

它也是第一個具有語義合併的現代版本控制系統——它理解選定的程式設計語言以及開發者對它們執行的重構。例如，「分支瀏覽器」，該方法長 50 行，不是一次提交新增 50 行和刪除 50 行，而是更精確和簡潔的差異表示。

Plastic 甚至可以冷靜地處理這樣一種情況：一個開發者在源中移動一個方法，而另一個開發者同時更改方法在其先前位置的內容。Plastic 根本不認為這是衝突，只是悄悄地進行合併——方法在其新位置移動並更改。