# 從 Subversion 過渡到 Git 目前，想從 Subversion 過渡到 Git 其實并不困難，只要你不把 Git 和 Subversion 混淆就行。一旦你明白了兩者在概念上的區別，這個改變的過程就會變得容易。 ## 分布式與集中式 Subversion 是一個_集中式（centralized）_的版本控制系統。所有的開發團隊成員都工作在單一的遠程中央倉庫上，當在這個中央倉庫上進行 “簽出（checkout）” 操作時，它就會在你的本地計算機上設置一個 “工作副本（working copy）”。這就是一個存儲在你本地計算機上的一個特定版本的快照。  Git 是一個_分部式（distributed）_的版本控制系統，它有著一個不同的工作方式。相對于 Subversion 的 “簽出（checkout）”，每一個 Git 用戶會從遠程倉庫 “克隆（clone）” 出一個本地倉庫。反過來說，一個用戶會得到一個完整的倉庫，而不僅僅只是一個工作副本。用戶在本地計算機上擁有自己的倉庫，并且包含所有的項目歷史記錄。 用戶可以在自己的本地計算機上做任何想要操作，例如提交（commit），歷史檢查（inspect history），恢復到一個舊的版本等等。只有當你想要共享你的工作結果時，你才需要連接到遠程服務器上。 ## 倉庫結構和 URLs 一個 Subversion 的倉庫通常都是由幾個目錄組織起來的。“trunk” 目錄對應你的開發主線，“branches” 目錄對應那些特定的工作背景下的開發，而 “tags” 目錄則用來標記一個特定的版本。它們都要通過自己的 URL 來指向到它在中央倉庫中的具體位置： ``` svn+ssh://svn@example.com/svn/trunk ``` Git 倉庫就完全不一樣了，它的組成完全就是一個在項目根目錄下的 “.git” 文件夾。對分支和標記的查找完全依靠命令，而不是通過 URLs。Git 的 URL 只指向倉庫的位置。 ``` ssh://git@example.com/path/to/git-repo.git ``` ## 分支 正如剛才提到的， Subversion 的分支僅僅是一些有特殊含義的目錄。在創建一個新的分支時，你只是把項目的當前狀態完完整整地拷貝到這個新的分支目錄中。 Git 的分支技術是它的設計核心，因此它擁有一個完全不同的概念。一個在 Git 中的分支就是一個指向一個特定版本的指針：不拷貝任何文件；不創建任何目錄；沒有任何額外的操作。 在 Git 中你 _永遠_ 工作在一個分支上，至少工作在那個系統默認創建的 “master” 分支上。在你的工作副本上只包括你當前的活動分支中的文件（ Git 稱之為 “HEAD”）。 所有其他的版本和分支都被保存在你的本地倉庫中， 并且隨時都可以非常快速地恢復到一個舊的版本。 一定要記住 Git 的分布式特性：分支可以被發布到在遠程服務器上，但是本地上的分支對于日常的工作更加重要。 ## 提交 當你想要在 Subversion 中提交一個改動，有如下的一些規則： * 你必須確保與中央倉庫的連接。你不能進行離線提交。 * 提交的內容要立即存儲在中央倉庫中。 * 它會被分配一個遞增版本號。 提交在 Git 中就是完全另外一種情況： * 你沒有必要連接到任何一個 “中央” 倉庫，因為在你的計算機中就擁有一個完整的本地倉庫。因此提交僅僅只記錄在本地倉庫上。它們不會自動地傳遞到遠程倉庫中，除非你自己決定共享這個改動。 * 文件的改動并不意味著它會被自動地包含在下一次提交中。你必須指明哪些改動你想要提交，并把它添加的所謂的 “暫存區（Staging Area）”中。你甚至可以只對文件的部分修改或是特定的幾行代碼進行提交，而其他部分則稍后提交。 * “commit hashes” 替代了版本號碼。由于提交都發生在開發人員的本地計算機上，你不可能給某個提交分配一個號碼 #5，而另外一個分配 #6，這就產生了個問題，在分布式系統下誰是第一個提交呢？在 Git 中，每一個提交必須擁有一個唯一的ID，因此一個哈希字符串就代替了那個依次遞增的版本號。 ## 分享工作 在 Subversion 中，在提交之后，你的工作會被自動地轉移到中央倉庫上去。只有在你連接到這個中央服務器時你才可以進行提交。 Git 不會自動上傳任何東西。你可以自己決定，你的那些分支（也可能是所有分支）需要共享給你其他的團隊成員。除此之外共享工作也是十分安全的。沖突只會出現在你的本地上，它決不可能發生在遠程服務器上。這會讓你有信心來解決沖突，因為你不會破壞遠程倉庫。