Git自學之路（一）- 認識瞭解後悔之藥Git

轉載請註明來源： http://blog.csdn.net/kjunchen/article/details/51981302

Git自學之路（一）- 認識瞭解後悔之藥Git

也許以前你不知道哪裏有後悔藥，但是當你遇見Git，你發現，想怎麼反悔就怎麼反悔，一言不合就撤退，對，就是這麼任性。

在代碼管理版本控制中，Git 是目前超級流行的工具。接下來就具體瞭解下 Git 的前世今生。 孫子曰：“知己知彼，百戰不殆”。因此， 對 Git 越瞭解應用也就越好。

關於版本控制

版本控制是一種記錄一個或若干個文件內容變化，以便將來查閱特定版本修訂情況的系統。 對於我們軟件工程師而言，我們對保存着軟件源代碼的文件作版本控制，但實際上，你可以對任何類型的文件進行版本控制。

如果你是位圖形或網頁設計師，可能會需要保存某一幅圖片或頁面佈局文件的所有修訂版本（這或許是你非常渴望擁有的功能），採用版本控制系統（VCS）是個明智的選擇。 有了它你就可以將某個文件回溯到之前的狀態，甚至將整個項目都回退到過去某個時間點的狀態，你可以比較文件的變化細節，查出最後是誰修改了哪個地方，從而找出導致怪異問題出現的原因，又是誰在何時報告了某個功能缺陷等等。使用版本控制系統通常還意味着，就算你亂來一氣把整個項目中的文件改的改刪的刪，你也照樣可以輕鬆恢復到原先的樣子。但額外增加的工作量卻微乎其微。

本地版本控制系統

許多人習慣用複製整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。這麼做唯一的好處就是簡單，但是特別容易犯錯。有時候會混淆所在的工作目錄，一不小心會寫錯文件或者覆蓋意想外的文件。

爲了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是採用某種簡單的數據庫來記錄文件的歷次更新差異。

其中最流行的一種叫做 RCS，現今許多計算機系統上都還看得到它的蹤影。

集中化的版本控制系統

接下來人們又遇到一個問題，如何讓在不同系統上的開發者協同工作？於是，集中化的版本控制系統（Centralized Version Control Systems，簡稱 CVCS）應運而生。 這類系統，諸如 CVS、Subversion 以及Perforce 等，都有一個單一的集中管理的服務器，保存所有文件的修訂版本，而協同工作的人們都通過客戶端連到這臺服務器，取出最新的文件或者提交更新。 多年以來，這已成爲版本控制系統的標準做法。

這種做法帶來了許多好處，特別是相較於老式的本地 VCS 來說。 現在，每個人都可以在一定程度上看到項目中的其他人正在做些什麼。 而管理員也可以輕鬆掌控每個開發者的權限，並且管理一個CVCS 要遠比在各個客戶端上維護本地數據庫來得輕鬆容易。

事分兩面，有好有壞。 這麼做最顯而易見的缺點是中央服務器的單點故障。 如果宕機一小時，那麼在這一小時內，誰都無法提交更新，也就無法協同工作。 如果中心數據庫所在的磁盤發生損壞，又沒有做恰當備份，毫無疑問你將丟失所有數據——包括項目的整個變更歷史，只剩下人們在各自機器上保留的單獨快照。 本地版本控制系統也存在類似問題，只要整個項目的歷史記錄被保存在單一位置，就有丟失所有歷史更新記錄的風險。

分佈式版本控制系統

於是分佈式版本控制系統（Distributed Version Control System，簡稱 DVCS）面世了。 在這類系統中，像Git、Mercurial、Bazaar 以及 Darcs等，客戶端並不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。 這麼一來，任何一處協同工作用的服務器發生故障，事後都可以用任何一個鏡像出來的本地倉庫恢復。因爲每一次的克隆操作，實際上都是一次對代碼倉庫的完整備份。

更進一步，許多這類系統都可以指定和若干不同的遠端代碼倉庫進行交互。籍此，你就可以在同一個項目中，分別和不同工作小組的人相互協作。 你可以根據需要設定不同的協作流程，比如層次模型式的工作流，而這在以前的集中式系統中是無法實現的。

Git簡史

Linux 內核開源項目有着爲數衆廣的參與者。 絕大多數的 Linux 內核維護工作都花在了提交補丁和保存歸檔的繁瑣事務上（1991－2002年間）。 到2002年，整個項目組開始啓用一個專有的分佈式版本控制系統BitKeeper來管理和維護代碼。

到了 2005 年，開發 BitKeeper 的商業公司同 Linux 內核開源社區的合作關係結束，他們收回了 Linux 內核社區免費使用BitKeeper的權力。這就迫使Linux開源社區（特別是Linux的締造者Linux Torvalds）基於使用BitKcheper 時的經驗教訓，開發出自己的版本系統。 他們對新的系統制訂了若干目標：

• 速度
• 簡單的設計
• 對非線性開發模式的強力支持（允許成千上萬個並行開發的分支）
• 完全分佈式
• 有能力高效管理類似 Linux 內核一樣的超大規模項目（速度和數據量）

自誕生於2005年以來，Git日臻成熟完善，在高度易用的同時，仍然保留着初期設定的目標。 它的速度飛快，極其適合管理大項目，有着令人難以置信的非線性分支管理系統。

Git基礎

那麼，Git 究竟是怎樣的一個系統呢？ 請注意接下來的內容非常重要，若你理解了 Git 的思想和基本工作原理，用起來就會知其所以然，遊刃有餘。 在開始學習 Git 的時候，請努力分清你對其它版本管理系統的已有認識，如 Subversion 和 Perforce 等；這麼做能幫助你使用工具時避免發生混淆。 Git 在保存和對待各種信息的時候與其它版本控制系統有很大差異，儘管操作起來的命令形式非常相近，理解這些差異將有助於防止你使用中的困惑。

直接記錄快照，而非差異比較

Git 和其它版本控制系統（包括 Subversion 和近似工具）的主要差別在於 Git對待數據的方法。 概念上來區分，其它大部分系統以文件變更列表的方式存儲信息。 這類系統（CVS、Subversion、Perforce等等）將它們保存的信息看作是一組基本文件和每個文件隨時間逐步累積的差異。

而 Git 更像是把數據看作是對小型文件系統的一組快照。 每次你提交更新，或在 Git 中保存項目狀態時，它主要對當時的全部文件製作一個快照並保存這個快照的索引。 爲了高效，如果文件沒有修改，Git 不再重新存儲該文件，而是隻保留一個鏈接指向之前存儲的文件。 Git對待數據更像是一個快照流。

這是 Git 與幾乎所有其它版本控制系統的重要區別。 因此 Git 重新考慮了以前每一代版本控制系統延續下來的諸多方面。 Git 更像是一個小型的文件系統，提供了許多以此爲基礎構建的超強工具，而不只是一個簡單的 VCS。

近乎所有操作都是本地執行

在 Git 中的絕大多數操作都只需要訪問本地文件和資源，一般不需要來自網絡上其它計算機的信息。 如果你習慣於所有操作都有網絡延時開銷的集中式版本控制系統，Git 在這方面會讓你感到速度之神賜給了Git超凡的能量。因爲你在本地磁盤上就有項目的完整歷史，所以大部分操作看起來瞬間完成。

舉個例子，要瀏覽項目的歷史，Git不需外連到服務器去獲取歷史，然後再顯示出來——它只需直接從本地數據庫中讀取。 你能立即看到項目歷史。 如果你想查看當前版本與一個月前的版本之間引入的修改，Git會查找到一個月前的文件做一次本地的差異計算，而不是由遠程服務器處理或從遠程服務器拉回舊版本文件再來本地處理。

這也意味着你離線或者沒有 VPN 時，幾乎可以進行任何操作。 如你在飛機或火車上想做些工作，你能愉快地提交，直到有網絡連接時再上傳。 如你回家後 VPN 客戶端不正常，你仍能工作。 使用其它系統，做到如此是不可能或很費力的。 比如，用 Perforce，你沒有連接服務器時幾乎不能做什麼事；用 Subversion 和 CVS，你能修改文件，但不能向數據庫提交修改（因爲你的本地數據庫離線了）。 這看起來不是大問題，但是你可能會驚喜地發現它帶來的巨大的不同。

Git保證完整性

Git 中所有數據在存儲前都計算校驗和，然後以校驗和來引用。 這意味着不可能在 Git 不知情時更改任何文件內容或目錄內容。 這個功能建構在 Git 底層，是構成 Git 哲學不可或缺的部分。 若你在傳送過程中丟失信息或損壞文件，Git 就能發現。

Git 用以計算校驗和的機制叫做 SHA-1 散列（hash，哈希）。 這是一個由 40 個十六進制字符（0-9 和 a-f）組成字符串，基於 Git 中文件的內容或目錄結構計算出來。 SHA-1 哈希看起來是這樣：

24b9da6552252987aa493b52f8696cd6d3b00373

Git 中使用這種哈希值的情況很多，你將經常看到這種哈希值。 實際上，Git 數據庫中保存的信息都是以文件內容的哈希值來索引，而不是文件名。

Git一般只添加數據

你執行的 Git 操作，幾乎只往 Git 數據庫中增加數據。 很難讓 Git 執行任何不可逆操作，或者讓它以任何方式清除數據。 同別的VCS一樣，未提交更新時有可能丟失或弄亂修改的內容；但是一旦你提交快照到Git中，就難以再丟失數據，特別是如果你定期的推送數據庫到其它倉庫的話。

這使得我們使用 Git 成爲一個安心愉悅的過程，因爲我們深知可以盡情做各種嘗試，而沒有把事情弄糟的危險。

三種狀態

注意。 如果你希望後面的學習更順利，記住下面這些關於 Git 的概念。 Git 有三種狀態，你的文件可能處於其中之一：已提交（committed）、已修改（modified）和已暫存（staged）。 已提交表示數據已經安全的保存在本地數據庫中。 已修改表示修改了文件，但還沒保存到數據庫中。 已暫存表示對一個已修改文件的當前版本做了標記，使之包含在下次提交的快照中。

由此引入 Git 項目的三個工作區域的概念：Git 倉庫、工作目錄以及暫存區域。

Git 倉庫目錄是 Git 用來保存項目的元數據和對象數據庫的地方。 這是 Git 中最重要的部分，從其它計算機克隆倉庫時，拷貝的就是這裏的數據。

工作目錄是對項目的某個版本獨立提取出來的內容。 這些從 Git 倉庫的壓縮數據庫中提取出來的文件，放在磁盤上供你使用或修改。

暫存區域是一個文件，保存了下次將提交的文件列表信息，一般在 Git 倉庫目錄中。 有時候也被稱作`‘索引’’，不過一般說法還是叫暫存區域。

基本的 Git 工作流程如下：

1. 在工作目錄中修改文件。
2. 暫存文件，將文件的快照放入暫存區域。
3. 提交更新，找到暫存區域的文件，將快照永久性存儲到 Git 倉庫目錄。

如果 Git 目錄中保存着的特定版本文件，就屬於已提交狀態。 如果作了修改並已放入暫存區域，就屬於已暫存狀
態。 如果自上次取出後，作了修改但還沒有放到暫存區域，就是已修改狀態。

命令行

Git 有多種使用方式。 你可以使用原生的命令行模式，也可以使用 GUI 模式，這些 GUI 軟件也能提供多種功能。一般使用命令行模式。 這是因爲首先，只有在命令行模式下你才能執行 Git 的 所有命令，而大多數的GUI軟件只實現了Git所有功能的一個子集以降低操作難度。 如果你學會了在命令行下如何操作，那麼你在操作GUI軟件時應該也不會遇到什麼困難，但是，反之則不成立。此外，由於每個人的想法與側重點不同，不同的人常常會安裝不同的GUI軟件，但所有人一定會有命令行工具。

假如你是 Mac 用戶，應懂得如何使用終端（Terminal）；假如你是 Windows 用戶，應懂得如何使用命令窗口（Command Prompt）或 PowerShell。

安裝Git

在你開始使用 Git 前，需要將他安裝在你的計算機上。即便已經安裝，最好將它升級到最新的版本。

在Linux上安裝

如果你想在 Linux 上用二進制安裝程序來安裝 Git，可以使用發行版包含的基礎軟件包管理工具來安裝。 如果以Fedora 上爲例，你可以使用 yum：

$ sudo yum install git

如果你在基於 Debian 的發行版上，請嘗試用 apt-get：

$ sudo apt-get install git

要了解更多選擇，Git 官方網站上有在各種 Unix 風格的系統上安裝步驟，網址爲 http://git-scm.com/download/linux。

在 Mac 上安裝

在 Mac 上安裝 Git 有多種方式。 最簡單的方法是安裝Xcode Command Line Tools。 Mavericks （10.9） 或更高版本的系統中，在 Terminal 裏嘗試首次運行 git 命令即可。 如果沒有安裝過命令行開發者工具，將會提示你安裝。

如果你想安裝更新的版本，可以使用二進制安裝程序。 官方維護的 OSX Git 安裝程序可以在 Git 官方網站下載，
網址爲 http://git-scm.com/download/mac。

在 Windows 上安裝

在 Windows 上安裝 Git 也有幾種安裝方法。 官方版本可以在 Git 官方網站下載。打開 http://git-scm.com/download/win，下載會自動開始。 要注意這是一個名爲 Git for Windows的項目（也叫做msysGit），和 Git 是分別獨立的項目；更多信息請訪問 http://msysgit.github.io/。

另一個簡單的方法是安裝 GitHub for Windows。 該安裝程序包含圖形化和命令行版本的 Git。它也能支持Powershell，提供了穩定的憑證緩存和健全的 CRLF 設置。 稍後我們會對這方面有更多瞭解，現在只要一句話就夠了，這些都是你所需要的。你可以在 GitHub for Windows 網站下載，網址爲 http://windows.github.com。

Windows上安裝軟件大家懂的，基本就一直下一步就可以了。安裝好了，接下就盡情享受你的 Git 之旅吧，有了 Git 媽媽在也不擔心我的代碼丟失了，呵呵。

Git自學之路（二）- Git初始配置和基本使用: http://blog.csdn.net/kjunchen/article/details/51998004

歡迎加QQ羣交流： 365532949
Homepage: http://junkchen.com