.jpg)
git屬于分布式版本控制系統(tǒng)。Git是Linus Torvalds為了幫助管理linux內(nèi)核開發(fā)而開發(fā)的一個(gè)開源的分布式版本控制軟件，用以有效、高速的處理從很小到非常大的項(xiàng)目版本管理。
本教程操作環(huán)境：windows7系統(tǒng)、mysql8.0.22版本、Dell G3電腦。
git屬于什么版本的控制系統(tǒng)
git是分布式版本控制系統(tǒng)。
Git具有以下特點(diǎn)：
-
Git中每個(gè)克隆(clone)的版本庫都是平等的。你可以從任何一個(gè)版本庫的克隆來創(chuàng)建屬于你自己的版本庫，同時(shí)你的版本庫也可以作為源提供給他人，只要你愿意。
-
Git的每一次提取操作，實(shí)際上都是一次對代碼倉庫的完整備份。
-
提交完全在本地完成，無須別人給你授權(quán)，你的版本庫你作主，并且提交總是會成功。
-
甚至基于舊版本的改動(dòng)也可以成功提交，提交會基于舊的版本創(chuàng)建一個(gè)新的分支。
-
Git的提交不會被打斷，直到你的工作完全滿意了，PUSH給他人或者他人PULL你的版本庫，合并會發(fā)生在PULL和PUSH過程中，不能自動(dòng)解決的沖突會提示您手工完成。
-
沖突解決不再像是svn一樣的提交競賽，而是在需要的時(shí)候才進(jìn)行合并和沖突解決。
-
Git 也可以模擬集中式的工作模式
-
Git版本庫統(tǒng)一放在服務(wù)器中
-
可以為 Git 版本庫進(jìn)行授權(quán)：誰能創(chuàng)建版本庫，誰能向版本庫PUSH，誰能夠讀取（克隆）版本庫
-
團(tuán)隊(duì)的成員先將服務(wù)器的版本庫克隆到本地；并經(jīng)常的從服務(wù)器的版本庫拉（PULL）最新的更新；
-
團(tuán)隊(duì)的成員將自己的改動(dòng)推（PUSH）到服務(wù)器的版本庫中，當(dāng)其他人和版本庫同步（PULL）時(shí)，會自動(dòng)獲取改變
-
Git 的集中式工作模式非常靈活
-
你完全可以在脫離Git服務(wù)器所在網(wǎng)絡(luò)的情況下，如移動(dòng)辦公／出差時(shí)，照常使用代碼庫
-
你只需要在能夠接入Git服務(wù)器所在網(wǎng)絡(luò)時(shí)，PULL和PUSH即可完成和服務(wù)器同步以及提交
-
Git提供 rebase 命令，可以讓你的改動(dòng)看起來是基于最新的代碼實(shí)現(xiàn)的改動(dòng)
-
Git 有更多的工作模式可以選擇，遠(yuǎn)非 Subversion可比
什么是“版本控制”？
?????? 版本控制是一種記錄一個(gè)或若干文件內(nèi)容變化，以便將來查閱特定版本修訂情況以及回溯的系統(tǒng)。 任何類型的文件都可以進(jìn)行版本控制。
????? 如果你是位圖形或網(wǎng)頁設(shè)計(jì)師，可能會需要保存某一幅圖片或頁面布局文件的所有修訂版本（這或許是你非常渴望擁有的功能），采用版本控制系統(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)通常還意味著，就算你亂來一氣把整個(gè)項(xiàng)目中的文件改的改刪的刪，你也照樣可以輕松恢復(fù)到原先的樣子。 但額外增加的工作量卻微乎其微。
本地版本控制系統(tǒng)
???? 許多人習(xí)慣用復(fù)制整個(gè)項(xiàng)目目錄的方式來保存不同的版本，或許還會改名加上備份時(shí)間以示區(qū)別。 這么做唯一的好處就是簡單，但是特別容易犯錯(cuò)。 有時(shí)候會混淆所在的工作目錄，一不小心會寫錯(cuò)文件或者覆蓋意想外的文件。
???? 為了解決這個(gè)問題，人們很久以前就開發(fā)了許多種本地版本控制系統(tǒng)，大多都是采用某種簡單的數(shù)據(jù)庫來記錄文件的歷次更新差異。
Figure 1. 本地版本控制.
????? 其中最流行的一種叫做 RCS，現(xiàn)今許多計(jì)算機(jī)系統(tǒng)上都還看得到它的蹤影。 甚至在流行的 Mac OS X 系統(tǒng)上安裝了開發(fā)者工具包之后，也可以使用?rcs?命令。 它的工作原理是在硬盤上保存補(bǔ)丁集（補(bǔ)丁是指文件修訂前后的變化）；通過應(yīng)用所有的補(bǔ)丁，可以重新計(jì)算出各個(gè)版本的文件內(nèi)容。
集中化的版本控制系統(tǒng)
接下來人們又遇到一個(gè)問題，如何讓在不同系統(tǒng)上的開發(fā)者協(xié)同工作？
????? 于是，集中化的版本控制系統(tǒng)（Centralized Version Control Systems，簡稱 CVCS）應(yīng)運(yùn)而生。 這類系統(tǒng)，諸如 CVS、Subversion?以及 Perforce 等，都有一個(gè)單一的集中管理的服務(wù)器，保存所有文件的修訂版本，而協(xié)同工作的人們都通過客戶端連到這臺服務(wù)器，取出最新的文件或者提交更新。 多年以來，這已成為版本控制系統(tǒng)的標(biāo)準(zhǔn)做法。
Figure 2. 集中化的版本控制.
?????? 這種做法帶來了許多好處，特別是相較于老式的本地 VCS 來說。 現(xiàn)在，每個(gè)人都可以在一定程度上看到項(xiàng)目中的其他人正在做些什么。 而管理員也可以輕松掌控每個(gè)開發(fā)者的權(quán)限，并且管理一個(gè) CVCS 要遠(yuǎn)比在各個(gè)客戶端上維護(hù)本地?cái)?shù)據(jù)庫來得輕松容易。
???????事分兩面，有好有壞。?這么做最顯而易見的缺點(diǎn)是中央服務(wù)器的單點(diǎn)故障。 如果宕機(jī)一小時(shí)，那么在這一小時(shí)內(nèi)，誰都無法提交更新，也就無法協(xié)同工作。 如果中心數(shù)據(jù)庫所在的磁盤發(fā)生損壞，又沒有做恰當(dāng)備份，毫無疑問你將丟失所有數(shù)據(jù)——包括項(xiàng)目的整個(gè)變更歷史，只剩下人們在各自機(jī)器上保留的單獨(dú)快照。 本地版本控制系統(tǒng)也存在類似問題，只要整個(gè)項(xiàng)目的歷史記錄被保存在單一位置，就有丟失所有歷史更新記錄的風(fēng)險(xiǎn)。
分布式版本控制系統(tǒng)
????? 于是分布式版本控制系統(tǒng)（Distributed Version Control System，簡稱 DVCS）面世了。 在這類系統(tǒng)中，像?Git、Mercurial、Bazaar 以及 Darcs 等，客戶端并不只提取最新版本的文件快照，而是把代碼倉庫完整地鏡像下來。 這么一來，任何一處協(xié)同工作用的服務(wù)器發(fā)生故障，事后都可以用任何一個(gè)鏡像出來的本地倉庫恢復(fù)。 因?yàn)槊恳淮蔚目寺〔僮鳎瑢?shí)際上都是一次對代碼倉庫的完整備份。
Figure 3. 分布式版本控制.
????? 更進(jìn)一步，許多這類系統(tǒng)都可以指定和若干不同的遠(yuǎn)端代碼倉庫進(jìn)行交互。籍此，你就可以在同一個(gè)項(xiàng)目中，分別和不同工作小組的人相互協(xié)作。 你可以根據(jù)需要設(shè)定不同的協(xié)作流程，比如層次模型式的工作流，而這在以前的集中式系統(tǒng)中是無法實(shí)現(xiàn)的。
.png)
