版本控制是一種記錄一個(gè)或若干文件內(nèi)容變化，以便將來查閱特定版本修訂情況的系統(tǒng)。除了項(xiàng)目，你可以對(duì)任何類型的文件進(jìn)行版本控制。

成都創(chuàng)新互聯(lián)公司服務(wù)項(xiàng)目包括鞏義網(wǎng)站建設(shè)、鞏義網(wǎng)站制作、鞏義網(wǎng)頁制作以及鞏義網(wǎng)絡(luò)營(yíng)銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，鞏義網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到鞏義省份的部分城市，未來相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

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

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

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

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

相對(duì)本地版本管理，集中化的版本控制每個(gè)人都可以在一定程度上看到項(xiàng)目中的其他人正在做些什么。 而管理員也可以輕松掌控每個(gè)開發(fā)者的權(quán)限，并且管理一個(gè) CVCS 要遠(yuǎn)比在各個(gè)客戶端上維護(hù)本地?cái)?shù)據(jù)庫來得輕松容易。

它也有如下詬?。?/p>

1. 單點(diǎn)故障如果宕機(jī)，誰都無法提交更新，也就無法協(xié)同工作。 如果中心數(shù)據(jù)庫所在的磁盤發(fā)生損壞，又沒有做恰當(dāng)備份，毫無疑問將丟失所有數(shù)據(jù)——包括項(xiàng)目的整個(gè)變更歷史，只剩下人們?cè)诟髯詸C(jī)器上保留的單獨(dú)快照。

2. 需要聯(lián)網(wǎng)為什么需要聯(lián)網(wǎng)？ 集中化的版本控制系統(tǒng) 倉(cāng)庫集中在一臺(tái)服務(wù)器，也就受到服務(wù)器網(wǎng)絡(luò)環(huán)境的影響。

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

客戶端并不只提取最新版本的文件快照，而是把代碼倉(cāng)庫完整地鏡像下來。 這么一來，任何一處協(xié)同工作用的服務(wù)器發(fā)生故障，事后都可以用任何一個(gè)鏡像出來的本地倉(cāng)庫恢復(fù)。 因?yàn)槊恳淮蔚目寺〔僮鳎瑢?shí)際上都是一次對(duì)代碼倉(cāng)庫的完整備份。圖片來源 Git 官網(wǎng)。

分布式版本控制系統(tǒng)的優(yōu)勢(shì)不單是不必聯(lián)網(wǎng)這么簡(jiǎn)單，后面我們還會(huì)看到 Git 極其強(qiáng)大的分支管理等功能。

2002 年， Linux 內(nèi)核開源項(xiàng)目整個(gè)項(xiàng)目組啟用一個(gè)專有的分布式版本控制系統(tǒng) BitKeeper 來管理和維護(hù)代碼。到了 2005 年，開發(fā) BitKeeper 的商業(yè)公司同 Linux 內(nèi)核開源社區(qū)的合作關(guān)系結(jié)束，他們收回了 Linux 內(nèi)核社區(qū)免費(fèi)使用 BitKeeper 的權(quán)力。 這就迫使 Linux 開源社區(qū)(特別是 Linux 的締造者 Linus Torvalds)基于使用 BitKeeper 時(shí)的經(jīng)驗(yàn)教訓(xùn)，開發(fā)出自己的版本系統(tǒng)。

集中式的缺點(diǎn)：集中式版本控制系統(tǒng)最大的毛病就是必須聯(lián)網(wǎng)才能工作，如果在局域網(wǎng)內(nèi)還好， 帶寬夠大， 速度夠快。

1. 分布式版本控制系統(tǒng)根本沒有“中央服務(wù)器”，每個(gè)人的電腦上都是一個(gè)完整的版本庫，這樣，你工作的時(shí)候，就不需要聯(lián)網(wǎng)了，因?yàn)榘姹編炀驮谀阕约旱碾娔X上。既然每個(gè)人電腦上都有一個(gè)完整的版本庫。

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

1. 和集中式版本控制系統(tǒng)相比，分布式版本控制系統(tǒng)的安全性要高很多，因?yàn)槊總€(gè)人電腦里都有完整的版本庫。

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

在實(shí)際使用分布式版本控制系統(tǒng)的時(shí)候，其實(shí)很少在兩人之間的電腦上推送版本庫的修改，因?yàn)榭赡苣銈儌z不在一個(gè)局域網(wǎng)內(nèi)，兩臺(tái)電腦互相訪問不了，也可能今天你的同事病了，他的電腦壓根沒有開機(jī)。因此，分布式版本控制系統(tǒng)通常也有一臺(tái)充當(dāng)“中央服務(wù)器”的電腦，但這個(gè)服務(wù)器的作用僅僅是用來方便“交換”大家的修改，沒有它大家也一樣干活，只是交換修改不方便而已。

Git的存儲(chǔ)方式是 快照技術(shù) ,而其他版本控制系統(tǒng)的存儲(chǔ)基本上都是 增量存儲(chǔ)。以下圖片來自網(wǎng)絡(luò)。

Git在每次 git add 即將內(nèi)容添加到 緩存區(qū) 時(shí)會(huì)進(jìn)行一次快照， 快照 就像給當(dāng)時(shí)的整個(gè)目錄及文件照了一張相，在任何時(shí)候通過快照就能將目錄及文件恢復(fù)到發(fā)起快照點(diǎn)的狀態(tài)。Git 是這樣生成快照的，對(duì)于沒有變化的文件，會(huì)生成一個(gè)引用指向原文件的位置以節(jié)省空間提高效率，對(duì)于變化了的文件則將整個(gè)文件存儲(chǔ)。git每個(gè)版本存儲(chǔ)的是一個(gè)快照。

所謂 增量存儲(chǔ) ,指的是除了第一個(gè)版本存儲(chǔ)的是每個(gè)文件的完整內(nèi)容，之后的版本存儲(chǔ)的是每個(gè)文件相對(duì)于上一個(gè)版本對(duì)應(yīng)文件的變化的內(nèi)容。

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

在 Git 中，文件狀態(tài)是個(gè)非常重要的概念。

為了更清楚的說明 文件狀態(tài) 的概念，使用網(wǎng)絡(luò)上三張圖片。

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

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

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

可以看到，除了之前的“Changes to be committed”狀態(tài)，現(xiàn)在又多了一條“Changes not staged for commit”狀態(tài)，表明文件已經(jīng)修改，但是還沒有放入暫存區(qū)域，也就是沒生成快照。如果現(xiàn)在進(jìn)行commit操作，只是將修改之前的文件快照提交到了git目錄，一定記住：只有暫存區(qū)域的文件（即：文件狀態(tài)為“Changes to be committed”）才會(huì)被提交。正如提示，通過“git add README.txt”命令將已修改文件更新到暫存區(qū)域中，如果想撤銷修改，可以使用“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 的其他版本系統(tǒng)需要其他方式安裝。

直接在官網(wǎng)下載。

另一種是在 Github ，搜索 GitHub for Windows 項(xiàng)目。

• 第一種：

新建一個(gè)存項(xiàng)目文件夾，在 git bash 執(zhí)行 git init ，項(xiàng)目文件夾下出現(xiàn) .git 的子目錄。

• 第二種

從遠(yuǎn)程代碼倉(cāng)庫拉去一個(gè)現(xiàn)有的： git clone [url]  也可以自定義本地倉(cāng)庫名字 git clone [url] dirName

進(jìn)入 Git 項(xiàng)目目錄

cd /myProject

提交 所有修改到暫存區(qū)

git add .

提交暫存區(qū)修改內(nèi)容到本地倉(cāng)庫

git commit -m "提交描述"

推送到遠(yuǎn)程倉(cāng)庫

git push

現(xiàn)在就可以拉去 JavaPub 的遠(yuǎn)程倉(cāng)庫了。

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

• 推送到遠(yuǎn)程倉(cāng)庫： git push origin master 推送到遠(yuǎn)程 master 分支

• 如果沒有遠(yuǎn)程倉(cāng)庫，現(xiàn)在想讓本地和遠(yuǎn)程倉(cāng)庫關(guān)聯(lián)， 如下命令添加： git remote add origin <server> ,比如我們要讓本地的一個(gè)倉(cāng)庫和 Github 上創(chuàng)建的一個(gè)倉(cāng)庫關(guān)聯(lián)可以這樣 git remote add origin https://github.com/Rodert/test.git

現(xiàn)在就可以將項(xiàng)目推送到遠(yuǎn)程倉(cāng)庫了。

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

只看某人提交記錄

git log --author=bob

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

git commit --amend

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

git reset filename

分支是用來將特性開發(fā)絕緣開來的。在你創(chuàng)建倉(cāng)庫的時(shí)候， master 是默認(rèn)的。在其他分支上進(jìn)行開發(fā)，完成后再將它們合并到主分支上。

不同的版本或系統(tǒng)模塊并行開發(fā)時(shí)，我們一般會(huì)單獨(dú)建立一個(gè)分支進(jìn)行開發(fā)，最后再合并到主分支。

• 新建本地分支

git branch test

• 切換到 test 分支

git checkout test

也可以合并上面?zhèn)z步， git checkout -b feature_x。

• 切換到 master 分支

git checkout master

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

git merge test

• 把新建的分支刪掉

git branch -d test

• 另外，也可以把分支推送到遠(yuǎn)程倉(cāng)庫 git push <遠(yuǎn)程主機(jī)名> <本地分支名>:<遠(yuǎn)程分支名>

git push origin test:test

聲明：參考來源互聯(lián)網(wǎng)，有任何爭(zhēng)議可以留言。站在前人的肩上，我們才能看的更遠(yuǎn)。

本教程純手打，致力于最實(shí)用教程，不需要什么獎(jiǎng)勵(lì)，只希望多多轉(zhuǎn)發(fā)支持。