版本控制是一種記錄一個或若干文件內容變化，以便將來查閱特定版本修訂情況的系統。除了項目，你可以對任何類型的文件進行版本控制。

采用版本控制系統(VCS)是個明智的選擇。 有了它就可以將某個文件回溯到之前的狀態，甚至將整個項目都回退到過去某個時間點的狀態，可以比較文件的變化細節，查出最后是誰修改了哪個地方，從而找出導致怪異問題出現的原因，又是誰在何時報告了某個功能缺陷等等。 使用版本控制系統就算你對項目刪除、修改錯誤，這也沒有關系，你也照樣可以很容易地就恢復到原先的樣子。但額外增加的工作量卻微乎其微。

許多人習慣用復制整個項目目錄的方式來保存不同的版本，或許還會改名加上備份時間以示區別。 這么做唯一的好處就是簡單，但是特別容易犯錯。 有時候會混淆所在的工作目錄，一不小心會寫錯文件或者覆蓋意想外的文件。而且不利于團隊協作。 為了解決這個問題，人們很久以前就開發了許多種本地版本控制系統，大多都是采用某種簡單的數據庫來記錄文件的歷次更新差異。圖片來源 Git 官網。

其中最流行的一種叫做 RCS，現今許多計算機系統上都還看得到它的蹤影。 甚至在流行的 Mac OS X 系統上安裝了開發者工具包之后，也可以使用 rcs 命令。 它的工作原理是在硬盤上保存補丁集(補丁是指文件修訂前后的變化)；通過應用所有的補丁，可以重新計算出各個版本的文件內容。

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

相對本地版本管理，集中化的版本控制每個人都可以在一定程度上看到項目中的其他人正在做些什么。 而管理員也可以輕松掌控每個開發者的權限，并且管理一個 CVCS 要遠比在各個客戶端上維護本地數據庫來得輕松容易。

它也有如下詬病：

1. 單點故障如果宕機，誰都無法提交更新，也就無法協同工作。 如果中心數據庫所在的磁盤發生損壞，又沒有做恰當備份，毫無疑問將丟失所有數據——包括項目的整個變更歷史，只剩下人們在各自機器上保留的單獨快照。

2. 需要聯網為什么需要聯網？ 集中化的版本控制系統 倉庫集中在一臺服務器，也就受到服務器網絡環境的影響。

于是分布式版本控制系統(Distributed Version Control System，簡稱 DVCS)面世了。 Git 就是典型的分布式版本控制。還有 Mercurial、 Bazaar 以及 Darcs 等。

客戶端并不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。 這么一來，任何一處協同工作用的服務器發生故障，事后都可以用任何一個鏡像出來的本地倉庫恢復。 因為每一次的克隆操作，實際上都是一次對代碼倉庫的完整備份。圖片來源 Git 官網。

分布式版本控制系統的優勢不單是不必聯網這么簡單，后面我們還會看到 Git 極其強大的分支管理等功能。

2002 年， Linux 內核開源項目整個項目組啟用一個專有的分布式版本控制系統 BitKeeper 來管理和維護代碼。到了 2005 年，開發 BitKeeper 的商業公司同 Linux 內核開源社區的合作關系結束，他們收回了 Linux 內核社區免費使用 BitKeeper 的權力。 這就迫使 Linux 開源社區(特別是 Linux 的締造者 Linus Torvalds)基于使用 BitKeeper 時的經驗教訓，開發出自己的版本系統。

集中式的缺點：集中式版本控制系統最大的毛病就是必須聯網才能工作，如果在局域網內還好， 帶寬夠大， 速度夠快。

1. 分布式版本控制系統根本沒有“中央服務器”，每個人的電腦上都是一個完整的版本庫，這樣，你工作的時候，就不需要聯網了，因為版本庫就在你自己的電腦上。既然每個人電腦上都有一個完整的版本庫。

比方說你在自己電腦上改了文件A，你的同事也在他的電腦上改了文件A，這時，你們倆之間只需把各自的修改推送給對方，就可以互相看到對方的修改了。

1. 和集中式版本控制系統相比，分布式版本控制系統的安全性要高很多，因為每個人電腦里都有完整的版本庫。

某一個人的電腦壞掉了不要緊，隨便從其他人那里復制一個就可以了。而集中式版本控制系統的中央服務器要是出了問題，所有人都沒法干活了。

在實際使用分布式版本控制系統的時候，其實很少在兩人之間的電腦上推送版本庫的修改，因為可能你們倆不在一個局域網內，兩臺電腦互相訪問不了，也可能今天你的同事病了，他的電腦壓根沒有開機。因此，分布式版本控制系統通常也有一臺充當“中央服務器”的電腦，但這個服務器的作用僅僅是用來方便“交換”大家的修改，沒有它大家也一樣干活，只是交換修改不方便而已。

Git的存儲方式是 快照技術 ,而其他版本控制系統的存儲基本上都是 增量存儲。以下圖片來自網絡。

Git在每次 git add 即將內容添加到 緩存區 時會進行一次快照， 快照 就像給當時的整個目錄及文件照了一張相，在任何時候通過快照就能將目錄及文件恢復到發起快照點的狀態。Git 是這樣生成快照的，對于沒有變化的文件，會生成一個引用指向原文件的位置以節省空間提高效率，對于變化了的文件則將整個文件存儲。git每個版本存儲的是一個快照。

所謂 增量存儲 ,指的是除了第一個版本存儲的是每個文件的完整內容，之后的版本存儲的是每個文件相對于上一個版本對應文件的變化的內容。

Git 在未進行 commit 操作之前，存在三種狀態： Untracked files， Changes not staged for commit 及 Changes to be committed ，每種狀態之間可以隨意進行互相轉換。了解這三種狀態各自所對應的不同情況，能夠幫助你方便有效的使用 Git 來管理項目。

在 Git 中，文件狀態是個非常重要的概念。

為了更清楚的說明 文件狀態 的概念，使用網絡上三張圖片。

• 初始化一個項目，也就是將項目所在目錄納入Git的管理之下。假設項目目錄為hello_world，初始化之后，在目錄下新建README.txt文件，接著，使用“git status”查看文件狀態，如圖

• 可以看到，Git友好的標示出README.txt為“Untracked files”，并且提示使用“git add...”的命令將文件包含到待提交清單中。按照提示，使用“git add README.txt”命令，然后，使用“git status”查看文件狀態，如圖：

• 文件README.txt狀態變成了“Changes to be committed”，也就是說README.txt在暫存區域生成了快照，等待被提交。正如Git所提示的那樣，通過“git rm --cached README.txt”命令，可以將文件狀態還原為未暫存狀態，即回到“Untracked files”文件狀態。現在，README.txt已經可以被提交到git目錄中了，但是暫時不提交。打開README.txt，向其中加些內容，保存之后，用“git status”查看，返回如圖信息：

可以看到，除了之前的“Changes to be committed”狀態，現在又多了一條“Changes not staged for commit”狀態，表明文件已經修改，但是還沒有放入暫存區域，也就是沒生成快照。如果現在進行commit操作，只是將修改之前的文件快照提交到了git目錄，一定記住：只有暫存區域的文件（即：文件狀態為“Changes to be committed”）才會被提交。正如提示，通過“git add README.txt”命令將已修改文件更新到暫存區域中，如果想撤銷修改，可以使用“git checkout -- README.txt”命令。

• Centos/RedHat 安裝

$ yum install curl-devel expat-devel gettext-devel
openssl-devel zlib-devel

$ yum -y install git-core

$ git --version git version 1.7.1

Linux 的其他版本系統需要其他方式安裝。

直接在官網下載。

另一種是在 Github ，搜索 GitHub for Windows 項目。

• 第一種：

新建一個存項目文件夾，在 git bash 執行 git init ，項目文件夾下出現 .git 的子目錄。

• 第二種

從遠程代碼倉庫拉去一個現有的： git clone [url]  也可以自定義本地倉庫名字 git clone [url] dirName

進入 Git 項目目錄

cd /myProject

提交 所有修改到暫存區

git add .

提交暫存區修改內容到本地倉庫

git commit -m "提交描述"

推送到遠程倉庫

git push

現在就可以拉去 JavaPub 的遠程倉庫了。

• 忽略文件配置： .gitignore 文件
• 移除文件： git rm filename(從暫存區移除，然后提交)
• 查看文件狀態： git status

• 推送到遠程倉庫： git push origin master 推送到遠程 master 分支

• 如果沒有遠程倉庫，現在想讓本地和遠程倉庫關聯， 如下命令添加： git remote add origin <server> ,比如我們要讓本地的一個倉庫和 Github 上創建的一個倉庫關聯可以這樣 git remote add origin https://github.com/Rodert/test.git

現在就可以將項目推送到遠程倉庫了。

有時我們需要查詢以前的提交歷史，使用命令 git log。

只看某人提交記錄

git log --author=bob

有時你提交過代碼之后，發現一個地方改錯了，你下次提交時不想保留上一次的記錄；或者你上一次的 commit message的描述有誤，這時候你可以使用接下來的這個命令： git commit --amend。

git commit --amend

取消上一步操作，如 git add 、 git commit 之后。

git reset filename

分支是用來將特性開發絕緣開來的。在你創建倉庫的時候， master 是默認的。在其他分支上進行開發，完成后再將它們合并到主分支上。

不同的版本或系統模塊并行開發時，我們一般會單獨建立一個分支進行開發，最后再合并到主分支。

• 新建本地分支

git branch test

• 切換到 test 分支

git checkout test

也可以合并上面倆步， git checkout -b feature_x。

• 切換到 master 分支

git checkout master

• 合并分支 （可能有沖突）

git merge test

• 把新建的分支刪掉

git branch -d test

• 另外，也可以把分支推送到遠程倉庫 git push <遠程主機名> <本地分支名>:<遠程分支名>

git push origin test:test

聲明：參考來源互聯網，有任何爭議可以留言。站在前人的肩上，我們才能看的更遠。

本教程純手打，致力于最實用教程，不需要什么獎勵，只希望多多轉發支持。