集中式版本控制工具
而版本控制工具其實有兩種,一種就是今天談到的Git這種分佈式版本控制工具，而另外一種就是SVN這種集中式版本控制工具。SVN的大名可能很多人都聽說過，集中式這個詞其實已經可以體現這種版本控制工具的缺點，集中式版本控制工具必須聯網才能使用，而且版本庫都有一個單一的集中管理的服務器，用於管理所有文件的所有修改版本，我們工作之前需要先從中央服務器取得最新的版本，然後進行修改，當我們修改完成之後，肯定要將我們的更新回傳到SVN進行更新版本庫。這時候如果有其他同事先於你之前更新，可能會報錯：改動基於過時的版本，先更新再提交。所以說使用SVN這類集中式版本控制工具會導致一個問題：先完成工作的先更新不會出現問題，後完成工作的還得處理舊版本導致的代碼衝突問題。這些都是SVN的缺點所在，但是SVN這類集中式版本控制工具最致命的缺點在於如果集中管理版本庫的中央服務器出現問題，而又沒有及時備份，有可能導致丟失整個項目的所有歷史更改記錄。
分佈式版本控制工具
說完了集中式版本控制工具，接下來我們說說分佈式版本控制工具。分佈式版本控制工具最爲流行的就是Git。分佈式版本控制工具可以在每個人的電腦中創建一個完整的版本庫，因此分佈式版本控制工具集中不需要存在一臺統一管理版本庫的服務器。那我們針對剛纔說過的SVN的缺點來說明爲什麼我們要採用Git。
Git如何協同合作
剛纔說過集中式版本控制工具必須聯網才能使用，而且版本庫都有一個單一的集中管理的服務器，用於管理所有文件的所有修改版本，但是Git實際上在本地磁盤就保存着項目的所有歷史更新版本，而且由於Git大部分都是操作本地資源所以完全不需要聯網操作。Git其實一般也會存在一臺電腦充當中央服務器的功能，但是實際上這臺中央服務器不是用於統一管理版本庫，而是用於同事之間交換修改使用。比如你將你的版本庫提交到中央服務器，你的同事想要同步你的代碼只需要將中央服務器的版本庫pull下來與本地代碼進行合併就可以，當同事工作完成上傳中央服務器，我們也只需要pull代碼進行合併，就可以在同事間很輕鬆的實現版本庫的同步。剛纔說到SVN有一個缺點：先完成工作的同事先更新不會出現問題，後完成工作的同事還得處理舊版本導致的代碼衝突問題。但是在Git中不會出現這種提交競賽，不同同事可以依次提交自己更新的部分，就算使用的版本庫已經是舊版的一樣可以上傳，會在使用的舊版本的基礎上新開一個分支，然後每次更新都會更新到這個分支，到某一天這個功能完全實現了，然後將幾個同事開發的幾個分支合併到主分支就可以進行合併代碼。我們舉個例子解釋下：比如有三個同事同事基於某個v1.0.0版本開發，A同事更新代碼後更新成功，B同事更新代碼，由於A已經更新了版本，所以這時候我們可以有兩個選擇，第一種就是鋼刺啊說的pull代碼與本地代碼合併再提交，或者這時候由於各自負責的功能還在開發，我們可以在這個v1.0.0的版本上創建一個新的分支，進行版本的更新迭代。一個月後整個功能完成了，這時候我們就可以合併三個同事的三個分支成爲一個分支。
Git如何讓做好備份工作
我們剛纔一直在說Git在本地創建版本庫，那版本庫存儲在本地磁盤，本地磁盤出問題我的所有版本庫不就直接全部丟失了。我們可以這樣操作：比如在D盤創建一個版本庫，然後在F盤創建一個備份版本庫，每次提交push到備份版本庫，就可以實現版本庫備份。
Git的優勢
Git 和 Svn 的分支實現機制完全的不同，這也直接導致了 SVN 在分支合併中困難重重。當我們使用SVN中在一個分支上工作數週或幾個月之後，主幹的修改也同時在進行着，兩條線的開發會區別巨大，當你想合併分支回主幹，可能因爲太多衝突，已經無法輕易合併你的分支和主幹的修改。而在 git 版本庫中創建分支的成本幾乎爲零，所以可以創建一個屬於自己的個人工作分支，以避免對主分支 master 造成太多的干擾，也方便與他人交流協作。當最後功能完成最後需要合併分支來合併別人修改的時候，最好創建一個臨時的分支用來合併，合併完成再fatch到自己的分支。
Git的缺點
中文完整的Git學習資料較少。
學習週期比較長。
代碼一經pull，就可以完全公開源碼和版本信息。
本文分享自微信公衆號 - 程序猿周先森（zhanyue_org）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。