GIT概念

集中式vs分布式

先說集中式版本控制系統(tǒng)，版本庫(kù)是集中存放在中央服務(wù)器的，而干活的時(shí)候，用的都是自己的電腦，所以要先從中央服務(wù)器取得最新的版本，然后開始干活，干完活了，再把自己的活推送給中央服務(wù)器。中央服務(wù)器就好比是一個(gè)圖書館，你要改一本書，必須先從圖書館借出來，然后回到家自己改，改完了，再放回圖書館。

集中式版本控制系統(tǒng)最大的毛病就是必須聯(lián)網(wǎng)才能工作，如果在局域網(wǎng)內(nèi)還好，帶寬夠大，速度夠快，可如果在互聯(lián)網(wǎng)上，遇到網(wǎng)速慢的話，可能提交一個(gè)10M的文件就需要5分鐘。

分布式版本控制系統(tǒng)根本沒有“中央服務(wù)器”，每個(gè)人的電腦上都是一個(gè)完整的版本庫(kù)，這樣，你工作的時(shí)候，就不需要聯(lián)網(wǎng)了，因?yàn)榘姹編?kù)就在你自己的電腦上。既然每個(gè)人電腦上都有一個(gè)完整的版本庫(kù)，那多個(gè)人如何協(xié)作呢？比方說你在自己電腦上改了文件A，你的同事也在他的電腦上改了文件A，這時(shí)，你們倆之間只需把各自的修改推送給對(duì)方，就可以互相看到對(duì)方的修改了。

和集中式版本控制系統(tǒng)相比，分布式版本控制系統(tǒng)的安全性要高很多，因?yàn)槊總€(gè)人電腦里都有完整的版本庫(kù)，某一個(gè)人的電腦壞掉了不要緊，隨便從其他人那里復(fù)制一個(gè)就可以了。而集中式版本控制系統(tǒng)的中央服務(wù)器要是出了問題，所有人都沒法干活了。

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

版本庫(kù)

版本庫(kù)又名倉(cāng)庫(kù)，英文名repository，你可以簡(jiǎn)單理解成一個(gè)目錄，這個(gè)目錄里面的所有文件都可以被Git管理起來，每個(gè)文件的修改、刪除，Git都能跟蹤，以便任何時(shí)刻都可以追蹤歷史，或者在將來某個(gè)時(shí)刻可以“還原”。

工作區(qū)和暫存區(qū)

Git和其他版本控制系統(tǒng)如SVN的一個(gè)不同之處就是有暫存區(qū)的概念。

工作區(qū)（Working Directory）
就是你在電腦里能看到的目錄，

版本庫(kù)（Repository）

工作區(qū)有一個(gè)隱藏目錄.git，這個(gè)不算工作區(qū)，而是Git的版本庫(kù)。

Git的版本庫(kù)里存了很多東西，其中最重要的就是稱為stage（或者叫index）的暫存區(qū)，還有Git為我們自動(dòng)創(chuàng)建的第一個(gè)分支master，以及指向master的一個(gè)指針叫HEAD。

因?yàn)槲覀儎?chuàng)建Git版本庫(kù)時(shí)，Git自動(dòng)為我們創(chuàng)建了唯一一個(gè)master分支，所以，現(xiàn)在，git commit就是往master分支上提交更改。

你可以簡(jiǎn)單理解為，需要提交的文件修改通通放到暫存區(qū)，然后，一次性提交暫存區(qū)的所有修改。

分支

分支就是科幻電影里面的平行宇宙，當(dāng)你正在電腦前努力學(xué)習(xí)Git的時(shí)候，另一個(gè)你正在另一個(gè)平行宇宙里努力學(xué)習(xí)SVN。

分支在實(shí)際中有什么用呢？假設(shè)你準(zhǔn)備開發(fā)一個(gè)新功能，但是需要兩周才能完成，第一周你寫了50%的代碼，如果立刻提交，由于代碼還沒寫完，不完整的代碼庫(kù)會(huì)導(dǎo)致別人不能干活了。如果等代碼全部寫完再一次提交，又存在丟失每天進(jìn)度的巨大風(fēng)險(xiǎn)。

現(xiàn)在有了分支，就不用怕了。你創(chuàng)建了一個(gè)屬于你自己的分支，別人看不到，還繼續(xù)在原來的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到開發(fā)完畢后，再一次性合并到原來的分支上，這樣，既安全，又不影響別人工作。

其他版本控制系統(tǒng)如SVN等都有分支管理，但是用過之后你會(huì)發(fā)現(xiàn)，這些版本控制系統(tǒng)創(chuàng)建和切換分支比蝸牛還慢，簡(jiǎn)直讓人無法忍受，結(jié)果分支功能成了擺設(shè)，大家都不去用。

但Git的分支是與眾不同的，無論創(chuàng)建、切換和刪除分支，Git在1秒鐘之內(nèi)就能完成！無論你的版本庫(kù)是1個(gè)文件還是1萬個(gè)文件。

標(biāo)簽

發(fā)布一個(gè)版本時(shí)，我們通常先在版本庫(kù)中打一個(gè)標(biāo)簽（tag），這樣，就唯一確定了打標(biāo)簽時(shí)刻的版本。將來無論什么時(shí)候，取某個(gè)標(biāo)簽的版本，就是把那個(gè)打標(biāo)簽的時(shí)刻的歷史版本取出來。所以，標(biāo)簽也是版本庫(kù)的一個(gè)快照。

Git的標(biāo)簽雖然是版本庫(kù)的快照，但其實(shí)它就是指向某個(gè)commit的指針（跟分支很像對(duì)不對(duì)？但是分支可以移動(dòng)，標(biāo)簽不能移動(dòng)），所以，創(chuàng)建和刪除標(biāo)簽都是瞬間完成的。

Git有commit，為什么還要引入tag？

“請(qǐng)把上周一的那個(gè)版本打包發(fā)布，commit號(hào)是6a5819e...”

“一串亂七八糟的數(shù)字不好找！”

如果換一個(gè)辦法：

“請(qǐng)把上周一的那個(gè)版本打包發(fā)布，版本號(hào)是v1.2”

“好的，按照tag v1.2查找commit就行！”

所以，tag就是一個(gè)讓人容易記住的有意義的名字，它跟某個(gè)commit綁在一起。

GitHub

我們一直用GitHub作為免費(fèi)的遠(yuǎn)程倉(cāng)庫(kù)，如果是個(gè)人的開源項(xiàng)目，放到GitHub上是完全沒有問題的。其實(shí)GitHub還是一個(gè)開源協(xié)作社區(qū)，通過GitHub，既可以讓別人參與你的開源項(xiàng)目，也可以參與別人的開源項(xiàng)目。

在GitHub出現(xiàn)以前，開源項(xiàng)目開源容易，但讓廣大人民群眾參與進(jìn)來比較困難，因?yàn)橐獏⑴c，就要提交代碼，而給每個(gè)想提交代碼的群眾都開一個(gè)賬號(hào)那是不現(xiàn)實(shí)的，因此，群眾也僅限于報(bào)個(gè)bug，即使能改掉bug，也只能把diff文件用郵件發(fā)過去，很不方便。

但是在GitHub上，利用Git極其強(qiáng)大的克隆和分支功能，廣大人民群眾真正可以第一次自由參與各種開源項(xiàng)目了。

如何參與一個(gè)開源項(xiàng)目呢？比如人氣極高的bootstrap項(xiàng)目，這是一個(gè)非常強(qiáng)大的CSS框架，你可以訪問它的項(xiàng)目主頁(yè)https://github.com/twbs/bootstrap，點(diǎn)“Fork”就在自己的賬號(hào)下克隆了一個(gè)bootstrap倉(cāng)庫(kù)，然后，從自己的賬號(hào)下clone：

git clone git@github.com:michaelliao/bootstrap.git
一定要從自己的賬號(hào)下clone倉(cāng)庫(kù)，這樣你才能推送修改。如果從bootstrap的作者的倉(cāng)庫(kù)地址git@github.com:twbs/bootstrap.git克隆，因?yàn)闆]有權(quán)限，你將不能推送修改。

Bootstrap的官方倉(cāng)庫(kù)twbs/bootstrap、你在GitHub上克隆的倉(cāng)庫(kù)my/bootstrap，以及你自己克隆到本地電腦的倉(cāng)庫(kù)，他們的關(guān)系就像下圖顯示的那樣：

github-repos

如果你想修復(fù)bootstrap的一個(gè)bug，或者新增一個(gè)功能，立刻就可以開始干活，干完后，往自己的倉(cāng)庫(kù)推送。

如果你希望bootstrap的官方庫(kù)能接受你的修改，你就可以在GitHub上發(fā)起一個(gè)pull request。當(dāng)然，對(duì)方是否接受你的pull request就不一定了。

如果你沒能力修改bootstrap，但又想要試一把pull request，那就Fork一下我的倉(cāng)庫(kù)：https://github.com/michaelliao/learngit，創(chuàng)建一個(gè)your-github-id.txt的文本文件，寫點(diǎn)自己學(xué)習(xí)Git的心得，然后推送一個(gè)pull request給我，我會(huì)視心情而定是否接受。

版本回退

你不斷對(duì)文件進(jìn)行修改，然后不斷提交修改到版本庫(kù)里，就好比玩RPG游戲時(shí)，每通過一關(guān)就會(huì)自動(dòng)把游戲狀態(tài)存盤，如果某一關(guān)沒過去，你還可以選擇讀取前一關(guān)的狀態(tài)。有些時(shí)候，在打Boss之前，你會(huì)手動(dòng)存盤，以便萬一打Boss失敗了，可以從最近的地方重新開始。Git也是一樣，每當(dāng)你覺得文件修改到一定程度的時(shí)候，就可以“保存一個(gè)快照”，這個(gè)快照在Git中被稱為commit。一旦你把文件改亂了，或者誤刪了文件，還可以從最近的一個(gè)commit恢復(fù)，然后繼續(xù)工作，而不是把幾個(gè)月的工作成果全部丟失。


當(dāng)然了，在實(shí)際工作中，我們腦子里怎么可能記得一個(gè)幾千行的文件每次都改了什么內(nèi)容，不然要版本控制系統(tǒng)干什么。版本控制系統(tǒng)肯定有某個(gè)命令可以告訴我們歷史記錄，在Git中，我們用git log命令查看。


git log命令顯示從最近到最遠(yuǎn)的提交日志，我們可以看到3次提交，最近的一次是append GPL，上一次是add distributed，最早的一次是wrote a readme file。
如果嫌輸出信息太多，看得眼花繚亂的，可以試試加上--pretty=oneline參數(shù)。


每提交一個(gè)新版本，實(shí)際上Git就會(huì)把它們自動(dòng)串成一條時(shí)間線。如果使用可視化工具查看Git歷史，就可以更清楚地看到提交歷史的時(shí)間線：
git-log-timeline


Git的版本回退速度非常快，因?yàn)镚it在內(nèi)部有個(gè)指向當(dāng)前版本的HEAD指針，當(dāng)你回退版本的時(shí)候，Git僅僅是把HEAD從指向append GPL：
git-head
改為指向add distributed：
git-head-move


然后順便把工作區(qū)的文件更新了。所以你讓HEAD指向哪個(gè)版本號(hào)，你就把當(dāng)前版本定位在哪。


在Git中，總是有后悔藥可以吃的。當(dāng)你用$ git reset --hard HEAD^回退到add distributed版本時(shí)，再想恢復(fù)到append GPL，就必須找到append GPL的commit id。Git提供了一個(gè)命令git reflog用來記錄你的每一次命令：
$ git reflog


總結(jié)
HEAD指向的版本就是當(dāng)前版本，因此，Git允許我們?cè)诎姹镜臍v史之間穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log可以查看提交歷史，以便確定要回退到哪個(gè)版本。
要重返未來，用git reflog查看命令歷史，以便確定要回到未來的哪個(gè)版本。

http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/00137621280731812dec22ecc9b44f4b2ca1c680f181a5b000
GIT教程

總結(jié)

以上是生活随笔為你收集整理的GIT的概念的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。