GIT基礎(chǔ)培訓(xùn)教程

GIT基礎(chǔ)教程1、初識Git

Git是一款分布式版本控制系統(tǒng)，有別于CVS和SVN等集中式版本控制系統(tǒng)，Git可以讓研發(fā)團(tuán)隊更加高效的協(xié)同工作，從而提高生產(chǎn)率。使用Git，開發(fā)人員的工作不會因為貧乏的遭遇提交沖突而中斷，管理人員也無需為數(shù)據(jù)備份而擔(dān)心。經(jīng)過Linux這樣龐大的項目考研之后，Git被證明可以勝任任何規(guī)模的團(tuán)隊。2、Git初始化Git的初始化

首先通過下面命令查看git版本

#git–version

在開始使用Git之前，我們首先要用gitconfig命令設(shè)置一下git的配置變量，主要有以下幾步：

（1）配置姓名，這個將在提交的時候用到

#gitconfig--global“pang” #gitconfig--globaluser.emailpang@126.com

（2）設(shè)置一些別名，以便使用更為簡潔的子命令

#gitconfig--globalalias.cicommit

（3）開啟顏色顯示

#gitconfig--globalcolor.uitrue

創(chuàng)建版本庫及第一次提交

首先建立一個新的工作目錄，并在這個目錄下建立版本庫 #cd/path/to/my/workspace #mkdirdemo #cddemo #gitinit InitializedemptyGitrepositoryin/path/to/../demo/.git

從上面初始化的輸出信息來看，工作區(qū)創(chuàng)建了隱藏目錄.git #ls–aF ./../.git/

這個隱藏的.git目錄就是Git版本庫下面向工作區(qū)添加文件 #echo“Hello.”>welcome.txt

將這個文件添加到版本庫 #gitaddwelcome.txt

這里還沒有完，需要提交一次才能進(jìn)入版本庫 #gitcommit–m“initialized”

提交必須有提交說明，-m參數(shù)可以直接給出提交說明

為什么會有.git目錄

在非工作區(qū)執(zhí)行g(shù)it命令會因為找不到.git目錄而報錯 #cd/path/to/my/workspace #gitstatus

在工作區(qū)建立a/b/c目錄并進(jìn)入 #mkdir–pa/b/c #cda/b/c

顯示版本庫目錄 #gitrev-parse--git-dir

顯示工作區(qū)根目錄 #gitrev-parse--show-toplevel

顯示工作區(qū)間根目錄的相對目錄 #gitrev-parse--show-prefix

顯示當(dāng)前目錄到工作區(qū)的深度

#gitrev-parse--show-cdup

gitconfig命令的參數(shù)區(qū)別

執(zhí)行下面命令，將打開.git/config文件進(jìn)行編輯 #gitconfig-e

執(zhí)行下面命令，將打開/home/git/.gitconfig文件進(jìn)行編輯 #gitconfig-e--global

執(zhí)行下面命令，將打開/etc/gitconfig系統(tǒng)級配置文件進(jìn)行編輯 #gitconfig-e--system

以上三個配置文件分別是Git版本庫級別的配置文件、全局配置文件（用戶主目錄下）和系統(tǒng)級配置文件（/etc目錄下）。其優(yōu)先級別依次降低。

誰在提交？

在使用Git之前我們設(shè)置了全局變量，如果不設(shè)置會出現(xiàn)什么后果呢

執(zhí)行下面命令，刪除全局變量中的和user.email #gitconfig--unset--global #gitconfig--unset--globaluser.email

這樣一來，關(guān)于用戶的設(shè)置就被清空了，嘗試一下提交 #gitcommit--allow-empty-m“whodoescommit?”

由于沒有設(shè)置用戶，會給出一段警告。查看下提交記錄 #gitlog

可以看出Git對于用戶姓名進(jìn)行了大膽猜測，猜測用戶為當(dāng)前終端登錄用戶。

為了保證提交者信息的準(zhǔn)確性，需要對提交恢復(fù)用戶設(shè)置

#gitconfig--global“pang” #gitconfig--globaluser.emailpang@126.com #gitcommit--amend--allow-empty--reset-author

其中--amend參數(shù)表示是修補(bǔ)提交，對上一次提交進(jìn)行修補(bǔ)，而不會產(chǎn)生新的提交。

小結(jié)了解了Git如何初始化版本庫及進(jìn)行提交熟悉Git配置變量的設(shè)置3、Git暫存區(qū)修改能直接提交嗎？

首先更改welcome.txt文件，在文件后面追加一行。 #echo“Nicetomeetyou.”>>welcome.txt

比較本地與版本庫中得差異 #gitdiff

可以看到文件修改了，那么提交 #gitcommit-m“Appendaniceline.”

沒有成功，查看提交日志，也沒用新的記錄 #gitlog #gitstatus-s Mwelcom.txt

添加下修改文件 #gitaddwelcome.txt #gitdiff沒有差別，難道是被提交了？在看一下當(dāng)前狀態(tài)： #gitstatus-s Mwelcome.txt

兩次狀態(tài)輸出有細(xì)微的差別，雖然都是M（modified）標(biāo)示，但是位置不一樣。gitadd執(zhí)行前，M位于第二列，執(zhí)行后位于第一列。第一列表示版本庫與暫存區(qū)的比較，第二列表示工作區(qū)與暫存區(qū)的區(qū)別。通過下面命令進(jìn)一步體會： #echo“Byebye.”>>welcome.txt #gitstatus-s MMwelcome.txt #gitcommit-m“whichwersioncheckedin?” #gitstatus-s Mwelcome.txt

保存下我們的工作，后面的進(jìn)度恢復(fù)會用到。 #gitstash

理解Git暫存區(qū)masterobjectsaddcheckoutcommitresetHEAD圖中左側(cè)是工作區(qū)，右側(cè)是版本庫。版本庫包括暫存區(qū)，master分支，對象庫等。HEAD實際上是指向分支的一個游標(biāo)。圖中objects標(biāo)示的區(qū)域是Git的對象庫。當(dāng)對工作區(qū)的修改的文件執(zhí)行g(shù)itadd命令時，暫存區(qū)的目錄會被更新，同時工作區(qū)的文件會被寫入到對象庫中。當(dāng)執(zhí)行提交（gitcommit）時，master的目錄樹會根據(jù)暫存區(qū)做出相應(yīng)的更新。當(dāng)執(zhí)行g(shù)itresetHEAD命令時，暫存區(qū)的目錄樹會被master分支的目錄樹所替換。當(dāng)執(zhí)行g(shù)itcheckout.命令時，會用暫存區(qū)的文件置換工作區(qū)的文件。（危險）當(dāng)執(zhí)行g(shù)itcheckoutHEAD.命令時，會用master分支的內(nèi)容替換暫存區(qū)和工作區(qū)文件。（危險）

目錄瀏覽查看HEAD目錄樹 #gitls-tree--lHEAD

瀏覽暫存區(qū)目錄樹，先清除工作區(qū)改動 #gitclean-fd #gitcheckout.

對工作區(qū)做以下修改 #echo“Bye-bye.”>>welcome.txt #mikdir-pa/b/c #echo“Hello.”>a/b/c/hello.txt #gitadd. #echo“Bye-bye.”>>a/b/chello.txt #gitstatus-s #find.-path./.git-prune-o-type-printf“%-20p\t%s\n”GitDiff魔法masterobjectsGitdiffgitdiff--cachedHEADgitdiffHEAD小結(jié)了解Git的工作原理。了解status的用法。知道工作區(qū)，暫存區(qū)之間的區(qū)別。學(xué)會diff不同的用法。4、Git的對象Git里見得最多的就是40位16進(jìn)制的ID號了,產(chǎn)看最近一次提交 #gitlog-1--pretty=raw

通過提交日志，我們發(fā)現(xiàn)一個提交里含有3個ID： commit：本次提交的唯一標(biāo)示 tree：

本次提交所對應(yīng)的目錄樹 parent：

本次提交的父提交

研究git對象ID的一個重要武器就是gitcat-file命令 #gitcat-[ID]查看ID類型 #gitcat-[ID]查看ID內(nèi)容

通過這個命令就可以對歷史提交進(jìn)行追蹤了。對象庫Ide6956Treef58dParenta0c6commitIda0c6Tree190dParent9e8acommitIdf58dBlobfd3c|_welcome.txt

TreeIdfd3cHello.Blob對象庫ID為什么不用順序數(shù)字Git的提交為什么不用順序數(shù)字而采用40位16進(jìn)制，這是因為Git是一個分布式的版本控制系統(tǒng)。如果采用順序遞增的編號，只能保證本地版本庫的唯一性，在分發(fā)的時候難免會造成沖突。所以采用40位ID可以保證編號的全球唯一。40位的ID如何訪問？

對于人來說，要記住40位的16進(jìn)制數(shù)是很困難的，Git提供了很多方法可以方便的訪問這些ID。1、不必寫全I(xiàn)D，只采用開頭部分（一般4位以上），只有不與現(xiàn)有其他ID沖突即可。2、使用HEAD代表最新提交，則 HEAD^表示HEAD的父提交 HEAD~5表示HEAD^^^^^小結(jié)了解Git對象的概念通過ID追蹤歷史提交5、Git重置我們知道，master相當(dāng)于一個分支游標(biāo)，每次都指向最新的提交。但是既然是游標(biāo)，就應(yīng)該既可以向上“游動”，也可以向下“游動”。

下面來體會下master游標(biāo)是怎么變化的 #cat.git/refs/heads/master//查看master指向 #touchnew-commit.txt #gitaddnew-commit.txt #gitcommit-m”doesmasterchange?” #cat.git/refs/heads/master

下面，我們重置下master游標(biāo) #gitreset--hardHEAD^ #cat.git/refs/heads/master

可以看到，不僅剛才提交的文件沒了，連提交日志中的記錄也不見了。使用重置命令很危險，會徹底丟掉歷史。那么，利用瀏覽提交歷史的方法找到丟棄的ID，在使用重置恢復(fù)歷史嗎？不可能！因為重置讓提交歷史也改變了。 #gitlog

發(fā)現(xiàn)提交日志中被丟棄的提交已經(jīng)不存在了。所以我們無法通過丟棄的ID來進(jìn)行恢復(fù)。

那么，如果不小心進(jìn)行了錯誤的重置，應(yīng)該如何去挽救呢？

利用reflog挽救錯誤重置如果沒有記下被丟棄的提交ID，想要重置回原來的提交很麻煩。幸好Git提供了挽救機(jī)制。日志目錄下有專門記錄分支變更的文件。

查看最近5次變更記錄。 #tail-5.git/logs/refs/heads/master #gitreflogshowmaster|head-5

根據(jù)reflog顯示，master@{2}是最后一次提交 #gitresetmaster@{2} #gitlog

可以發(fā)現(xiàn)提交歷史也都恢復(fù)了。深入了解gitreset命令#gitreset[-q][<commit>][--]<paths>#gitreset[--soft|--hard…][-q][<commit>]

上面兩個用法，<commit>是可選項，省略則表示是HEAD指向的提交。

第一種用法包含路徑，不會重置引用，也不會改變工作區(qū)，相當(dāng)于取消了之前執(zhí)行的gitadd命令。

第二種則會重置引用，根據(jù)不同的選項可以對暫存區(qū)和工作區(qū)進(jìn)行重置。 --hard：替換引用；置換暫存區(qū)；置換工作區(qū)。 --soft：替換引用。

小結(jié)熟悉reset重置的用法。學(xué)會利用reflog恢復(fù)錯誤重置。6、Git檢出重置命令可以更改master的游標(biāo)指向，如何能夠改變HEAD的指向呢？HEAD可以理解為頭指針，是當(dāng)前工作區(qū)的“基礎(chǔ)版本”，當(dāng)執(zhí)行提交的時候，HEAD所指向的提交將作為新提交的父提交。下面查看下當(dāng)前HEAD的指向。 #cat.git/HEAD #gitbranch-v

用gitcheckout命令檢出當(dāng)前提交的父提交。 #gitcheckout[ID]^

查看下現(xiàn)在HEAD和master所對應(yīng)的提交ID。 #gitrev-parseHEADmaster

可以看出當(dāng)前頭指針和master已經(jīng)指向了不同的提交。即當(dāng)前是處于“分離頭指針”狀態(tài)。現(xiàn)在再做一次提交，HEAD會怎么變化呢？ #touchdetached-commit.txt #gitadddetached-commit.txt #gitcommit-m“commitindetachedHEADmode.” #cat.git/HEAD #gitlog--graph--pretty=oneline

可以看到HEAD指向了最新的提交，并且是建立在之前指向的提交之上的。下面切換到master分支上。 #gitcheckoutmaster

切換之后，HEAD重新指向了分支，而不是斷頭模式。但是剛才提交的日志也不見了。 #gitlog--graph--pretty=noeline

挽救分離頭指針，因為剛才的提交未被任何分支追蹤到，因此不能保證這個提交會永遠(yuǎn)存在于對象庫中。 #gitmerge[ID]

深入理解gitcheckout命令#gitcheckout[-q][<commit>][--]<paths>#gitcheckout[<branch>]#gitcheckout[-m][[-b|--orphan]<new_branch>][<start_point>]

第一種用法<commit>是可選項，如果省略則相當(dāng)于從暫存區(qū)進(jìn)行檢出。和重置命令不同，重置一般用于重置暫存區(qū)，而檢出主要是覆蓋工作區(qū)。這種用法不會改變HEAD，主要用于指定版本的文件覆蓋工作區(qū)的對應(yīng)文件。

第二種用法則會改變頭指針。只要HEAD切換到一個分支上才會被跟蹤，否則就會處于分離頭指針狀態(tài)。第二種用法主要是用于切換分支的。

第三種用法主要是用來創(chuàng)建并切換到新的分支的。新的分支從<start_point>指定的提交開始。小結(jié)了解檢出的作用初步了解檢出的用法7、進(jìn)度恢復(fù)

我們在暫存區(qū)一節(jié)保存了工作進(jìn)度Git可以通過下面命令恢復(fù)工作進(jìn)度。 #gitstashlist #gitstashpop

保存的進(jìn)度都恢復(fù)了，下面進(jìn)行提交。 #gitcommit-m“addnewleavewelcome.txt.”

后悔了，重置放棄最新的提交。 #gitreset--softHEAD^

添加welcome.txt，撤出a/b/c/hello.txt #gitaddwelcome.txt #gitresetHEADa/b/c/hello.txt

全部清除 #gitreset #gitcheckout--welcome.txt #gitclean-fdstash的用法： #echoByebye>>welcome.txt #echohello.>hack-1.txt #gitaddhack-1.txt #gitstashsave“hackedwelcome.txt,new”

工作區(qū)恢復(fù)了原貌，修改都不見了。 #echofix.>hack-2.txt #gitstash

現(xiàn)在有了兩個保存進(jìn)度，如何恢復(fù)第一個進(jìn)度 #gitstashapplystash@{1} #gitstashclear

小結(jié)學(xué)會stash的常用命令stashsavestashpopstashliststashapplystashclear8、刪除操作前面講的都是如何添加更改文件，下面是如何刪除文件。首先保存下當(dāng)前進(jìn)度。 #gitstash #gitstashapply

查看下當(dāng)前工作區(qū)都有哪些文件： #ls

直接在工作區(qū)刪除文件 #rm*.txt

通過下面命令，可以看到版本庫中文件還在 #gitls-files

結(jié)論：工作區(qū)刪除文件對版本庫無任何影響執(zhí)行g(shù)itrm命令刪除文件

根據(jù)上面的輸出的提示，我們應(yīng)該使用gitrm命令來刪除 #gitrmdetached-txthack-1.txtnew-commit.txtwelcome.txt

刪除動作被添加到了暫存區(qū)，這時候執(zhí)行提交動作，就從真正意義上執(zhí)行了文件刪除。

#gitcommit-m“deletefilesusinggitrm.”

但是，文件只是在版本庫的最新提交中刪除了，在歷史提交中還在?？梢酝ㄟ^下面的命令查看歷史版本的文件列表。 #gitls-files--with-tree=HEAD^

也可以查看歷史版本中刪除的文件內(nèi)容。 #gitcat-HEAD^:welcome.txtgitadd-u快速刪除

恢復(fù)下現(xiàn)場 #gitreset--hartHEAD^ #gitstashapply-q #rm*.txt #gitadd-u #gitcommit-m“deletefilesusinggitadd-u.”恢復(fù)刪除的文件經(jīng)過上面的操作，工作區(qū)已經(jīng)沒有了任何的文件。上面說過執(zhí)行刪除并提交，只是在提交中刪除了文件，在歷史版本中還存在。我們可以通過歷史版本來恢復(fù)文件。執(zhí)行下面命令可以恢復(fù)welcome.txt文件。 #gitcat-HEAD^:welcome.txt>welcome.txt或者 #gitshowHEAD^:welcome.txt>welcome.txt

當(dāng)然，使用checkout命令更為簡潔實用。（思考）

文件已經(jīng)被恢復(fù)到文件區(qū)了，提交到版本庫就可以了。 #gitadd-A #gitcommit-m“restorefiles.”

通過再次添加刪除文件是最自然的恢復(fù)方法。其他版本庫如CVS也采用同樣的方法。但是其他系統(tǒng)卻會帶來嚴(yán)重的副作用--文件變更歷史被人為割裂，或者是存儲空間的浪費(fèi)。Git卻沒有這種副作用。聯(lián)想下Git對象庫小結(jié)學(xué)會刪除文件的方法學(xué)會恢復(fù)刪除的方法9、Git克隆雞蛋不要裝在一個籃子里版本庫A版本庫B.git.gitgitclone①②A①：PUSH②：PULLB①：PULL②：PUSHgitclone克隆版本庫主要有三種用法

#gitclone<repository><directory> #gitclone--bare<repository><directory.git> #gitclone--mirror<repository><directory.git>

方法1是將repository指向的版本庫克隆到directory目錄下。文件都會檢出，版本庫位于工作區(qū)下的.git目錄中。

方法2和3創(chuàng)建的克隆版本庫都不包含工作區(qū)，直接就是版本庫的內(nèi)容，這樣的版本庫稱為裸版本庫。一般約定俗成裸版本庫的目錄以.git為后綴，所以上面示例中將克隆出來的裸版本庫目錄名寫作<directory.git>。

用法3區(qū)別于用法2之處在于用法3克隆出來的裸版本庫對上游版本庫進(jìn)行了注冊，這樣可以在裸版本庫中使用gitfetch命令和上游版本庫進(jìn)行持續(xù)同步。

對等工作區(qū)

#gitclone/path/../demo/path/../demo-backup #cddemo #gitcommit--allow-empty-m“test1” #gitcommit--allow-empty-m“test2” #gitpush/path/../demo-backup

出錯了，因為默認(rèn)更新非裸版本庫的當(dāng)前分支是不被允許的，這將會導(dǎo)致暫存區(qū)和工作區(qū)與推送至版本庫的提交不一致。 #cddemo-backup #gitpull #gitlog--oneline-2

為什么執(zhí)行pull命令沒有像push那么長的命令，因為在執(zhí)行clone命令時，克隆出來的版本庫對原版本庫進(jìn)行了注冊。所以執(zhí)行拉回的時候無需設(shè)置上游版本庫的地址。

克隆裸版本庫

#gitclone--bare/path/../demo/path/../demo.git #cddemo #gitcommit--allow-empty-m“test3” #gitcommit--allow-empty-m“test4” #gitpush/path/../demo.git

這次推送成功了，因為裸版本庫不存在工作區(qū)，因此不會造成當(dāng)前分支與工作區(qū)的不同。

創(chuàng)建生成裸版本庫裸版本庫不但可以通過克隆方式創(chuàng)建，還可以通過gitinit命令以初始化的方式創(chuàng)建，之后的同步與上面大同小異。 #gitinit--bare/path../demo-init.git #cd/path../demo #gitpush/path../demo-init.git

推送出錯了，這是由于創(chuàng)建的是裸版本庫，沒有工作分支，所以無法推送。 #gitpush/path../demo-init.gitmaster

加上參數(shù)master，表示推送到master分支上，推送成功。 #gitcommit--allow-empty-m“test5” #gitcommit--allow-empty-m“test6” #git