GIT概念

集中式vs分布式

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

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

分布式版本控制系統根本沒有“中央服務器”，每個人的電腦上都是一個完整的版本庫，這樣，你工作的時候，就不需要聯網了，因為版本庫就在你自己的電腦上。既然每個人電腦上都有一個完整的版本庫，那多個人如何協作呢？比方說你在自己電腦上改了文件A，你的同事也在他的電腦上改了文件A，這時，你們倆之間只需把各自的修改推送給對方，就可以互相看到對方的修改了。

和集中式版本控制系統相比，分布式版本控制系統的安全性要高很多，因為每個人電腦里都有完整的版本庫，某一個人的電腦壞掉了不要緊，隨便從其他人那里復制一個就可以了。而集中式版本控制系統的中央服務器要是出了問題，所有人都沒法干活了。

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

版本庫

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

工作區和暫存區

Git和其他版本控制系統如SVN的一個不同之處就是有暫存區的概念。

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

版本庫（Repository）

工作區有一個隱藏目錄.git，這個不算工作區，而是Git的版本庫。

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

因為我們創建Git版本庫時，Git自動為我們創建了唯一一個master分支，所以，現在，git commit就是往master分支上提交更改。

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

分支

分支就是科幻電影里面的平行宇宙，當你正在電腦前努力學習Git的時候，另一個你正在另一個平行宇宙里努力學習SVN。

分支在實際中有什么用呢？假設你準備開發一個新功能，但是需要兩周才能完成，第一周你寫了50%的代碼，如果立刻提交，由于代碼還沒寫完，不完整的代碼庫會導致別人不能干活了。如果等代碼全部寫完再一次提交，又存在丟失每天進度的巨大風險。

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

其他版本控制系統如SVN等都有分支管理，但是用過之后你會發現，這些版本控制系統創建和切換分支比蝸牛還慢，簡直讓人無法忍受，結果分支功能成了擺設，大家都不去用。

但Git的分支是與眾不同的，無論創建、切換和刪除分支，Git在1秒鐘之內就能完成！無論你的版本庫是1個文件還是1萬個文件。

標簽

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

Git的標簽雖然是版本庫的快照，但其實它就是指向某個commit的指針（跟分支很像對不對？但是分支可以移動，標簽不能移動），所以，創建和刪除標簽都是瞬間完成的。

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

“請把上周一的那個版本打包發布，commit號是6a5819e...”

“一串亂七八糟的數字不好找！”

如果換一個辦法：

“請把上周一的那個版本打包發布，版本號是v1.2”

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

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

GitHub

我們一直用GitHub作為免費的遠程倉庫，如果是個人的開源項目，放到GitHub上是完全沒有問題的。其實GitHub還是一個開源協作社區，通過GitHub，既可以讓別人參與你的開源項目，也可以參與別人的開源項目。

在GitHub出現以前，開源項目開源容易，但讓廣大人民群眾參與進來比較困難，因為要參與，就要提交代碼，而給每個想提交代碼的群眾都開一個賬號那是不現實的，因此，群眾也僅限于報個bug，即使能改掉bug，也只能把diff文件用郵件發過去，很不方便。

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

如何參與一個開源項目呢？比如人氣極高的bootstrap項目，這是一個非常強大的CSS框架，你可以訪問它的項目主頁https://github.com/twbs/bootstrap，點“Fork”就在自己的賬號下克隆了一個bootstrap倉庫，然后，從自己的賬號下clone：

git clone git@github.com:michaelliao/bootstrap.git
一定要從自己的賬號下clone倉庫，這樣你才能推送修改。如果從bootstrap的作者的倉庫地址git@github.com:twbs/bootstrap.git克隆，因為沒有權限，你將不能推送修改。

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

github-repos

如果你想修復bootstrap的一個bug，或者新增一個功能，立刻就可以開始干活，干完后，往自己的倉庫推送。

如果你希望bootstrap的官方庫能接受你的修改，你就可以在GitHub上發起一個pull request。當然，對方是否接受你的pull request就不一定了。

如果你沒能力修改bootstrap，但又想要試一把pull request，那就Fork一下我的倉庫：https://github.com/michaelliao/learngit，創建一個your-github-id.txt的文本文件，寫點自己學習Git的心得，然后推送一個pull request給我，我會視心情而定是否接受。

版本回退

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


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


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


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


Git的版本回退速度非常快，因為Git在內部有個指向當前版本的HEAD指針，當你回退版本的時候，Git僅僅是把HEAD從指向append GPL：
git-head
改為指向add distributed：
git-head-move


然后順便把工作區的文件更新了。所以你讓HEAD指向哪個版本號，你就把當前版本定位在哪。


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


總結
HEAD指向的版本就是當前版本，因此，Git允許我們在版本的歷史之間穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log可以查看提交歷史，以便確定要回退到哪個版本。
要重返未來，用git reflog查看命令歷史，以便確定要回到未來的哪個版本。

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。