git命令總結(jié) 1.創(chuàng)建版本庫(kù) 初始化一個(gè)版本庫(kù) git init <dir> 或者 cd <dir> git init 添加文件到版本庫(kù) git add <file> git commit -m "comment"
2.查看狀態(tài) 查看工作區(qū)狀態(tài) git status 如果git status告訴文件已經(jīng)被修改,查看修改內(nèi)容: git diff <file>
3.版本回退 HEAD 指向當(dāng)前版本,在版本的歷史記錄之間切換: git reset --hard commit_id 回退到上一版本: git reset --hard HEAD^ 回退到上上一版本: git reset --hard HEAD^^ 回退前100次版本 git reset --hard HEAD~100 查看版本歷史,以確定回退到哪個(gè)版本: git log git log --pretty=oneline git log --online --decorate --graph --all 要重返未來(lái),查看命令歷史: git reflog
4.管理修改 查看工作區(qū)和版本庫(kù)里面最新版本的區(qū)別 git diff HEAD -- <file>
5.撤銷修改 當(dāng)你改亂了工作區(qū)某個(gè)文件的內(nèi)容,想直接丟棄工作區(qū)的修改時(shí),用命令 git checkout -- <file> 文件在工作區(qū)的修改全部撤銷 當(dāng)你不但改亂了工作區(qū)某個(gè)文件的內(nèi)容,還添加到了暫存區(qū)時(shí),想丟棄修改,分兩步, 第一步用命令git reset HEAD <file>(把暫存區(qū)的修改撤銷),就回到了場(chǎng)景1 第二步按場(chǎng)景1操作。
已經(jīng)提交了不合適的修改到版本庫(kù)時(shí),想要撤銷本次提交,參考版本回退一節(jié),不過(guò)前提是沒(méi)有推送到遠(yuǎn)程庫(kù)。
6.刪除文件 git add test.txt git commit -m "add test.txt" rm test.txt git status git rm test.txt git commit -m "remove test.txt" 刪錯(cuò)了,因?yàn)榘姹編?kù)里還有呢,所以可以很輕松地把誤刪的文件恢復(fù)到最新版本: git checkout -- test.txt
7.配置github 第1步:創(chuàng)建SSH Key: 在用戶主目錄下,查看有沒(méi)有id_rsa和id_rsa.pub文件,有,跳下一步。 沒(méi)有,打開Shell(Windows下打開Git Bash),創(chuàng)建SSH Key: ssh-keygen -t rsa -C "youremail@example.com" 一路回車,使用默認(rèn)值即可,由于Key也不是用于軍事目的,無(wú)需設(shè)置密碼。 如果一切順利的話,可以在用戶主目錄里找到.ssh目錄,里面有id_rsa和id_rsa.pub兩個(gè)文件,這兩個(gè)就是SSH Key的秘鑰對(duì),id_rsa是私鑰,不能泄露出去,id_rsa.pub是公鑰,可以放心地告訴任何人。
第2步:登陸GitHub,打開“Account settings”,“SSH Keys”頁(yè)面: 然后,點(diǎn)“Add SSH Key”,填上任意Title,在Key文本框里粘貼id_rsa.pub文件的內(nèi)容后, 點(diǎn)“Add Key”,你就應(yīng)該看到已經(jīng)添加的Key。
8.github上添加遠(yuǎn)程倉(cāng)庫(kù) 首先,登陸GitHub,然后,在右上角找到“Create a new repo”按鈕,創(chuàng)建一個(gè)新的倉(cāng)庫(kù) 在Repository name填入learngit,其他保持默認(rèn)設(shè)置,點(diǎn)擊“Create repository”按鈕,就成功地創(chuàng)建了一個(gè)新的Git倉(cāng)庫(kù):
將本地倉(cāng)庫(kù)與遠(yuǎn)程倉(cāng)庫(kù)關(guān)聯(lián): git remote add origin git@github.com:ileveli/learngit.git 添加后,遠(yuǎn)程庫(kù)的名字就是origin,這是Git默認(rèn)的叫法,也可以改成別的,但是origin這個(gè)名字一看就知道是遠(yuǎn)程庫(kù)。
就可以把本地庫(kù)的所有內(nèi)容推送到遠(yuǎn)程庫(kù)上: git push -u origin master 把本地庫(kù)的內(nèi)容推送到遠(yuǎn)程,用git push命令,實(shí)際上是把當(dāng)前分支master推送到遠(yuǎn)程。
推送成功后,可以立刻在GitHub頁(yè)面中看到遠(yuǎn)程庫(kù)的內(nèi)容已經(jīng)和本地一模一樣
從現(xiàn)在起,只要本地作了提交,就可以通過(guò)命令: git push origin master 把本地master分支的最新修改推送至GitHub,現(xiàn)在,你就擁有了真正的分布式版本庫(kù)!
小結(jié): 要關(guān)聯(lián)一個(gè)遠(yuǎn)程庫(kù),使用命令git remote add origin git@server-name:path/repo-name.git; 關(guān)聯(lián)后,使用命令git push -u origin master第一次推送master分支的所有內(nèi)容; 此后,每次本地提交后,只要有必要,就可以使用命令git push origin master推送最新修改;
9.從遠(yuǎn)程庫(kù)克隆 首先,登陸GitHub,創(chuàng)建一個(gè)新的倉(cāng)庫(kù),名字叫g(shù)itskills 我們勾選Initialize this repository with a README,這樣GitHub會(huì)自動(dòng)為我們創(chuàng)建一個(gè)README.md文件。創(chuàng)建完畢后,可以看到README.md文件 現(xiàn)在,遠(yuǎn)程庫(kù)已經(jīng)準(zhǔn)備好了,下一步是用命令git clone克隆一個(gè)本地庫(kù): git clone git@github.com:ileveli/gitskills.git 進(jìn)入gitskills目錄看看,已經(jīng)有README.md文件了。
小結(jié) 要克隆一個(gè)倉(cāng)庫(kù),首先必須知道倉(cāng)庫(kù)的地址,然后使用git clone命令克隆。 Git支持多種協(xié)議,包括https,但通過(guò)ssh支持的原生git協(xié)議速度最快。
10.創(chuàng)建與合并分支 創(chuàng)建dev分支,然后切換到dev分支: $ git checkout -b dev Switched to a new branch 'dev' git checkout命令加上-b參數(shù)表示創(chuàng)建并切換,相當(dāng)于以下兩條命令: $ git branch dev $ git checkout dev Switched to branch 'dev' 然后,用git branch命令查看當(dāng)前分支: $ git branch * dev master git branch命令會(huì)列出所有分支,當(dāng)前分支前面會(huì)標(biāo)一個(gè)*號(hào)。 然后,我們就可以在dev分支上正常提交,比如對(duì)readme.txt做個(gè)修改,加上一行: Creating a new branch is quick. 然后提交: $ git add readme.txt $ git commit -m "branch test" [dev fec145a] branch test 1 file changed, 1 insertion(+) 現(xiàn)在,dev分支的工作完成,我們就可以切換回master分支: $ git checkout master Switched to branch 'master' 切換回master分支后,再查看一個(gè)readme.txt文件,剛才添加的內(nèi)容不見了!因?yàn)槟莻€(gè)提交是在dev分支上,而master分支此刻的提交點(diǎn)并沒(méi)有變: 現(xiàn)在,我們把dev分支的工作成果合并到master分支上: $ git merge dev Updating d17efd8..fec145a Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+) git merge命令用于合并指定分支到當(dāng)前分支。合并后,再查看readme.txt的內(nèi)容,就可以看到,和dev分支的最新提交是完全一樣的。 注意到上面的Fast-forward信息,Git告訴我們,這次合并是“快進(jìn)模式”,也就是直接把master指向dev的當(dāng)前提交,所以合并速度非常快。 當(dāng)然,也不是每次合并都能Fast-forward,我們后面會(huì)講其他方式的合并。 合并完成后,就可以放心地刪除dev分支了: $ git branch -d dev Deleted branch dev (was fec145a). 刪除后,查看branch,就只剩下master分支了: $ git branch * master 因?yàn)閯?chuàng)建、合并和刪除分支非???,所以Git鼓勵(lì)你使用分支完成某個(gè)任務(wù),合并后再刪掉分支,這和直接在master分支上工作效果是一樣的,但過(guò)程更安全。
小結(jié) Git鼓勵(lì)大量使用分支: 查看分支:git branch 創(chuàng)建分支:git branch <name> 切換分支:git checkout <name> 創(chuàng)建+切換分支:git checkout -b <name> 合并某分支到當(dāng)前分支:git merge <name> 刪除分支:git branch -d <name>
11.解決沖突 準(zhǔn)備新的feature1分支,繼續(xù)我們的新分支開發(fā): $ git checkout -b feature1 Switched to a new branch 'feature1' 修改readme.txt最后一行,改為: Creating a new branch is quick AND simple. 在feature1分支上提交: $ git add readme.txt $ git commit -m "AND simple" [feature1 75a857c] AND simple 1 file changed, 1 insertion(+), 1 deletion(-) 切換到master分支: $ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 1 commit. Git還會(huì)自動(dòng)提示我們當(dāng)前master分支比遠(yuǎn)程的master分支要超前1個(gè)提交。 在master分支上把readme.txt文件的最后一行改為: Creating a new branch is quick & simple. 提交: $ git add readme.txt $ git commit -m "& simple" [master 400b400] & simple 1 file changed, 1 insertion(+), 1 deletion(-) 現(xiàn)在,master分支和feature1分支各自都分別有新的提交,變成了這樣: 這種情況下,Git無(wú)法執(zhí)行“快速合并”,只能試圖把各自的修改合并起來(lái),但這種合并就可能會(huì)有沖突,我們?cè)囋嚳矗?br> $ git merge feature1 Auto-merging readme.txt CONFLICT (content): Merge conflict in readme.txt Automatic merge failed; fix conflicts and then commit the result. 果然沖突了!Git告訴我們,readme.txt文件存在沖突,必須手動(dòng)解決沖突后再提交。git status也可以告訴我們沖突的文件: $ git status 我們可以直接查看readme.txt的內(nèi)容: Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files. <<<<<<< HEAD Creating a new branch is quick & simple. ======= Creating a new branch is quick AND simple. >>>>>>> feature1 Git用<<<<<<<,=======,>>>>>>>標(biāo)記出不同分支的內(nèi)容,我們修改如下后保存:
Creating a new branch is quick and simple. 再提交: $ git add readme.txt $ git commit -m "conflict fixed" [master 59bc1cb] conflict fixed 現(xiàn)在,master分支和feature1分支變成了下圖所示: 用帶參數(shù)的git log也可以看到分支的合并情況: $ git log --graph --pretty=oneline --abbrev-commit * 59bc1cb conflict fixed |\ | * 75a857c AND simple * | 400b400 & simple |/ * fec145a branch test ... 最后,刪除feature1分支: $ git branch -d feature1 Deleted branch feature1 (was 75a857c). 工作完成。
小結(jié) 當(dāng)Git無(wú)法自動(dòng)合并分支時(shí),就必須首先解決沖突。解決沖突后,再提交,合并完成。 用git log --graph命令可以看到分支合并圖。
12.分支管理策略 通常,合并分支時(shí),如果可能,Git會(huì)用Fast forward模式,但這種模式下,刪除分支后,會(huì)丟掉分支信息。 如果要強(qiáng)制禁用Fast forward模式,Git就會(huì)在merge時(shí)生成一個(gè)新的commit,這樣,從分支歷史上就可以看出分支信息。 下面我們實(shí)戰(zhàn)一下--no-ff方式的git merge: 首先,仍然創(chuàng)建并切換dev分支: $ git checkout -b dev Switched to a new branch 'dev' 修改readme.txt文件,并提交一個(gè)新的commit: $ git add readme.txt $ git commit -m "add merge" [dev 6224937] add merge 1 file changed, 1 insertion(+) 現(xiàn)在,我們切換回master: $ git checkout master Switched to branch 'master' 準(zhǔn)備合并dev分支,請(qǐng)注意--no-ff參數(shù),表示禁用Fast forward: $ git merge --no-ff -m "merge with no-ff" dev Merge made by the 'recursive' strategy. readme.txt | 1 + 1 file changed, 1 insertion(+) 因?yàn)楸敬魏喜⒁獎(jiǎng)?chuàng)建一個(gè)新的commit,所以加上-m參數(shù),把commit描述寫進(jìn)去。 合并后,我們用git log看看分支歷史: $ git log --graph --pretty=oneline --abbrev-commit * 7825a50 merge with no-ff |\ | * 6224937 add merge |/ * 59bc1cb conflict fixed ... 可以看到,不使用Fast forward模式,merge后就像這樣:
分支策略,在實(shí)際開發(fā)中,我們應(yīng)該按照幾個(gè)基本原則進(jìn)行分支管理: 首先,master分支應(yīng)該是非常穩(wěn)定的,也就是僅用來(lái)發(fā)布新版本,平時(shí)不能在上面干活; 那在哪干活呢?干活都在dev分支上,也就是說(shuō),dev分支是不穩(wěn)定的,到某個(gè)時(shí)候,比如1.0版本發(fā)布時(shí),再把dev分支合并到master上,在master分支發(fā)布1.0版本; 你和你的小伙伴們每個(gè)人都在dev分支上干活,每個(gè)人都有自己的分支,時(shí)不時(shí)地往dev分支上合并就可以了。 所以,團(tuán)隊(duì)合作的分支看起來(lái)就像這樣: git-br-policy
小結(jié) Git分支十分強(qiáng)大,在團(tuán)隊(duì)開發(fā)中應(yīng)該充分應(yīng)用。 合并分支時(shí),加上--no-ff參數(shù)就可以用普通模式合并,合并后的歷史有分支,能看出來(lái)曾經(jīng)做過(guò)合并,而fast forward合并就看不出來(lái)曾經(jīng)做過(guò)合并。
13.BUG分支 軟件開發(fā)中,bug就像家常便飯一樣。有了bug就需要修復(fù),在Git中,由于分支是如此的強(qiáng)大,所以,每個(gè)bug都可以通過(guò)一個(gè)新的臨時(shí)分支來(lái)修復(fù),修復(fù)后,合并分支,然后將臨時(shí)分支刪除。 當(dāng)你接到一個(gè)修復(fù)一個(gè)代號(hào)10的bug的任務(wù)時(shí),很自然地,你想創(chuàng)建一個(gè)分支issue-10來(lái)修復(fù)它,但是,等等,當(dāng)前正在dev上進(jìn)行的工作還沒(méi)有提交: $ git status 并不是你不想提交,而是工作只進(jìn)行到一半,還沒(méi)法提交,預(yù)計(jì)完成還需1天時(shí)間。但是,必須在兩個(gè)小時(shí)內(nèi)修復(fù)該bug,怎么辦? 幸好,Git還提供了一個(gè)stash功能,可以把當(dāng)前工作現(xiàn)場(chǎng)“儲(chǔ)藏”起來(lái),等以后恢復(fù)現(xiàn)場(chǎng)后繼續(xù)工作: $ git stash Saved working directory and index state WIP on dev: 6224937 add merge HEAD is now at 6224937 add merge 現(xiàn)在,用git status查看工作區(qū),就是干凈的(除非有沒(méi)有被Git管理的文件),因此可以放心地創(chuàng)建分支來(lái)修復(fù)bug。
首先確定要在哪個(gè)分支上修復(fù)bug,假定需要在master分支上修復(fù),就從master創(chuàng)建臨時(shí)分支: $ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. $ git checkout -b issue-10 Switched to a new branch 'issue-10' 現(xiàn)在修復(fù)bug,需要把“Git is free software ...”改為“Git is a free software ...”,然后提交: $ git add readme.txt $ git commit -m "fix bug 10" [issue-101 cc17032] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-) 修復(fù)完成后,切換到master分支,并完成合并,最后刪除issue-10分支: $ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 2 commits. $ git merge --no-ff -m "merged bug fix 101" issue-10 Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git branch -d issue-10 Deleted branch issue-10 (was cc17032). 太棒了,原計(jì)劃兩個(gè)小時(shí)的bug修復(fù)只花了5分鐘!現(xiàn)在,是時(shí)候接著回到dev分支干活了! $ git checkout dev Switched to branch 'dev' $ git status # On branch dev nothing to commit (working directory clean) 工作區(qū)是干凈的,剛才的工作現(xiàn)場(chǎng)存到哪去了?用git stash list命令看看: $ git stash list stash@{0}: WIP on dev: 6224937 add merge 工作現(xiàn)場(chǎng)還在,Git把stash內(nèi)容存在某個(gè)地方了,但是需要恢復(fù)一下,有兩個(gè)辦法: 一是用git stash apply恢復(fù),但是恢復(fù)后,stash內(nèi)容并不刪除,你需要用git stash drop來(lái)刪除; 另一種方式是用git stash pop,恢復(fù)的同時(shí)把stash內(nèi)容也刪了: $ git stash pop 再用git stash list查看,就看不到任何stash內(nèi)容了: $ git stash list 你可以多次stash,恢復(fù)的時(shí)候,先用git stash list查看,然后恢復(fù)指定的stash,用命令: $ git stash apply stash@{0}
小結(jié) 修復(fù)bug時(shí),我們會(huì)通過(guò)創(chuàng)建新的bug分支進(jìn)行修復(fù),然后合并,最后刪除; 當(dāng)手頭工作沒(méi)有完成時(shí),先把工作現(xiàn)場(chǎng)git stash一下,然后去修復(fù)bug,修復(fù)后,再git stash pop,回到工作現(xiàn)場(chǎng)。
14.Feature分支 軟件開發(fā)中,總有無(wú)窮無(wú)盡的新的功能要不斷添加進(jìn)來(lái)。 添加一個(gè)新功能時(shí),你肯定不希望因?yàn)橐恍?shí)驗(yàn)性質(zhì)的代碼,把主分支搞亂了,所以,每添加一個(gè)新功能,最好新建一個(gè)feature分支,在上面開發(fā),完成后,合并,最后,刪除該feature分支。 現(xiàn)在,你終于接到了一個(gè)新任務(wù):開發(fā)代號(hào)為Vulcan的新功能,該功能計(jì)劃用于下一代星際飛船。 于是準(zhǔn)備開發(fā): $ git checkout -b feature-vulcan Switched to a new branch 'feature-vulcan' 5分鐘后,開發(fā)完畢: $ git add vulcan.py $ git status $ git commit -m "add feature vulcan" [feature-vulcan 756d4af] add feature vulcan 1 file changed, 2 insertions(+) create mode 100644 vulcan.py 切回dev,準(zhǔn)備合并: $ git checkout dev 一切順利的話,feature分支和bug分支是類似的,合并,然后刪除。 但是,就在此時(shí),接到上級(jí)命令,因經(jīng)費(fèi)不足,新功能必須取消! 雖然白干了,但是這個(gè)分支還是必須就地銷毀: $ git branch -d feature-vulcan error: The branch 'feature-vulcan' is not fully merged. If you are sure you want to delete it, run 'git branch -D feature-vulcan'. 銷毀失敗。Git友情提醒,feature-vulcan分支還沒(méi)有被合并,如果刪除,將丟失掉修改,如果要強(qiáng)行刪除,需要使用命令git branch -D feature-vulcan。 現(xiàn)在我們強(qiáng)行刪除: $ git branch -D feature-vulcan Deleted branch feature-vulcan (was 756d4af). 終于刪除成功!
小結(jié) 開發(fā)一個(gè)新feature,最好新建一個(gè)分支; 如果要丟棄一個(gè)沒(méi)有被合并過(guò)的分支,可以通過(guò)git branch -D <name>強(qiáng)行刪除。
15.多人協(xié)作 當(dāng)你從遠(yuǎn)程倉(cāng)庫(kù)克隆時(shí),實(shí)際上Git自動(dòng)把本地的master分支和遠(yuǎn)程的master分支對(duì)應(yīng)起來(lái)了,并且,遠(yuǎn)程倉(cāng)庫(kù)的默認(rèn)名稱是origin。 要查看遠(yuǎn)程庫(kù)的信息,用git remote: $ git remote origin 或者,用git remote -v顯示更詳細(xì)的信息: $ git remote -v origin git@github.com:michaelliao/learngit.git (fetch) origin git@github.com:michaelliao/learngit.git (push) 上面顯示了可以抓取和推送的origin的地址。如果沒(méi)有推送權(quán)限,就看不到push的地址。
推送分支 推送分支,就是把該分支上的所有本地提交推送到遠(yuǎn)程庫(kù)。推送時(shí),要指定本地分支,這樣,Git就會(huì)把該分支推送到遠(yuǎn)程庫(kù)對(duì)應(yīng)的遠(yuǎn)程分支上: $ git push origin master 如果要推送其他分支,比如dev,就改成: $ git push origin dev 但是,并不是一定要把本地分支往遠(yuǎn)程推送,那么,哪些分支需要推送,哪些不需要呢? master分支是主分支,因此要時(shí)刻與遠(yuǎn)程同步; dev分支是開發(fā)分支,團(tuán)隊(duì)所有成員都需要在上面工作,所以也需要與遠(yuǎn)程同步; bug分支只用于在本地修復(fù)bug,就沒(méi)必要推到遠(yuǎn)程了,除非老板要看看你每周到底修復(fù)了幾個(gè)bug; feature分支是否推到遠(yuǎn)程,取決于你是否和你的小伙伴合作在上面開發(fā)。 總之,就是在Git中,分支完全可以在本地自己藏著玩,是否推送,視你的心情而定!
多人協(xié)作時(shí),大家都會(huì)往master和dev分支上推送各自的修改。
抓取分支 現(xiàn)在,模擬一個(gè)你的小伙伴,可以在另一臺(tái)電腦(注意要把SSH Key添加到GitHub)或者同一臺(tái)電腦的另一個(gè)目錄下克隆: $ git clone git@github.com:michaelliao/learngit.git 當(dāng)你的小伙伴從遠(yuǎn)程庫(kù)clone時(shí),默認(rèn)情況下,你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看: $ git branch * master 現(xiàn)在,你的小伙伴要在dev分支上開發(fā),就必須創(chuàng)建遠(yuǎn)程origin的dev分支到本地,于是他用這個(gè)命令創(chuàng)建本地dev分支: $ git checkout -b dev origin/dev 現(xiàn)在,他就可以在dev上繼續(xù)修改,然后,時(shí)不時(shí)地把dev分支push到遠(yuǎn)程: $ git commit -m "add /usr/bin/env" $ git push origin dev 你的小伙伴已經(jīng)向origin/dev分支推送了他的提交,而碰巧你也對(duì)同樣的文件作了修改,并試圖推送: $ git add hello.py $ git commit -m "add coding: utf-8" $ git push origin dev 推送失敗,因?yàn)槟愕男』锇榈淖钚绿峤缓湍阍噲D推送的提交有沖突,解決辦法也很簡(jiǎn)單,Git已經(jīng)提示我們,先用git pull把最新的提交從origin/dev抓下來(lái),然后,在本地合并,解決沖突,再推送: $ git pull git pull也失敗了,原因是沒(méi)有指定本地dev分支與遠(yuǎn)程origin/dev分支的鏈接,根據(jù)提示,設(shè)置dev和origin/dev的鏈接: $ git branch --set-upstream dev origin/dev 再pull: $ git pull 這回git pull成功,但是合并有沖突,需要手動(dòng)解決,解決的方法和分支管理中的解決沖突完全一樣。解決后,提交,再push: $ git commit -m "merge & fix hello.py" $ git push origin dev
多人協(xié)作的工作模式: 首先,可以試圖用git push origin branch-name推送自己的修改; 如果推送失敗,則因?yàn)檫h(yuǎn)程分支比你的本地更新,需要先用git pull試圖合并; 如果合并有沖突,則解決沖突,并在本地提交; 沒(méi)有沖突或者解決掉沖突后,再用git push origin branch-name推送就能成功! 如果git pull提示“no tracking information”,則說(shuō)明本地分支和遠(yuǎn)程分支的鏈接關(guān)系沒(méi)有創(chuàng)建,用命令git branch --set-upstream branch-name origin/branch-name。 這就是多人協(xié)作的工作模式,一旦熟悉了,就非常簡(jiǎn)單。
小結(jié) 查看遠(yuǎn)程庫(kù)信息,使用git remote -v; 本地新建的分支如果不推送到遠(yuǎn)程,對(duì)其他人就是不可見的; 從本地推送分支,使用git push origin branch-name,如果推送失敗,先用git pull抓取遠(yuǎn)程的新提交; 在本地創(chuàng)建和遠(yuǎn)程分支對(duì)應(yīng)的分支,使用git checkout -b branch-name origin/branch-name,本地和遠(yuǎn)程分支的名稱最好一致; 建立本地分支和遠(yuǎn)程分支的關(guān)聯(lián),使用git branch --set-upstream branch-name origin/branch-name; 從遠(yuǎn)程抓取分支,使用git pull,如果有沖突,要先處理沖突。
16.標(biāo)簽管理 發(fā)布一個(gè)版本時(shí),我們通常先在版本庫(kù)中打一個(gè)標(biāo)簽(tag),這樣,就唯一確定了打標(biāo)簽時(shí)刻的版本。將來(lái)無(wú)論什么時(shí)候,取某個(gè)標(biāo)簽的版本,就是把那個(gè)打標(biāo)簽的時(shí)刻的歷史版本取出來(lái)。所以,標(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綁在一起。
17.創(chuàng)建標(biāo)簽 在Git中打標(biāo)簽非常簡(jiǎn)單,首先,切換到需要打標(biāo)簽的分支上: $ git branch * dev master $ git checkout master Switched to branch 'master' 然后,敲命令git tag <name>就可以打一個(gè)新標(biāo)簽: $ git tag v1.0 可以用命令git tag查看所有標(biāo)簽: $ git tag v1.0 默認(rèn)標(biāo)簽是打在最新提交的commit上的。有時(shí)候,如果忘了打標(biāo)簽,比如,現(xiàn)在已經(jīng)是周五了,但應(yīng)該在周一打的標(biāo)簽沒(méi)有打,怎么辦? 方法是找到歷史提交的commit id,然后打上就可以了: $ git log --pretty=oneline --abbrev-commit 6a5819e merged bug fix 101 cc17032 fix bug 101 7825a50 merge with no-ff 6224937 add merge 59bc1cb conflict fixed 400b400 & simple 75a857c AND simple fec145a branch test d17efd8 remove test.txt ... 比方說(shuō)要對(duì)add merge這次提交打標(biāo)簽,它對(duì)應(yīng)的commit id是6224937,敲入命令: $ git tag v0.9 6224937 再用命令git tag查看標(biāo)簽: $ git tag v0.9 v1.0 注意,標(biāo)簽不是按時(shí)間順序列出,而是按字母排序的??梢杂胓it show <tagname>查看標(biāo)簽信息: $ git show v0.9 commit 622493706ab447b6bb37e4e2a2f276a20fed2ab4 Author: Michael Liao <askxuefeng@gmail.com> Date: Thu Aug 22 11:22:08 2013 +0800
add merge ... 可以看到,v0.9確實(shí)打在add merge這次提交上。
還可以創(chuàng)建帶有說(shuō)明的標(biāo)簽,用-a指定標(biāo)簽名,-m指定說(shuō)明文字: $ git tag -a v0.1 -m "version 0.1 released" 3628164 用命令git show <tagname>可以看到說(shuō)明文字: $ git show v0.1 tag v0.1 還可以通過(guò)-s用私鑰簽名一個(gè)標(biāo)簽: $ git tag -s v0.2 -m "signed version 0.2 released" fec145a 簽名采用PGP簽名,因此,必須首先安裝gpg(GnuPG),如果沒(méi)有找到gpg,或者沒(méi)有g(shù)pg密鑰對(duì),就會(huì)報(bào)錯(cuò): gpg: signing failed: secret key not available error: gpg failed to sign the data error: unable to sign the tag 如果報(bào)錯(cuò),請(qǐng)參考GnuPG幫助文檔配置Key。
用命令git show <tagname>可以看到PGP簽名信息: $ git show v0.2 tag v0.2 Tagger: Michael Liao <askxuefeng@gmail.com> Date: Mon Aug 26 07:28:33 2013 +0800 signed version 0.2 released -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iQEcBAABAgAGBQJSGpMhAAoJEPUxHyDAhBpT4QQIAKeHfR3bo... -----END PGP SIGNATURE----- commit fec145accd63cdc9ed95a2f557ea0658a2a6537f Author: Michael Liao <askxuefeng@gmail.com> Date: Thu Aug 22 10:37:30 2013 +0800 branch test 用PGP簽名的標(biāo)簽是不可偽造的,因?yàn)榭梢则?yàn)證PGP簽名。驗(yàn)證簽名的方法比較復(fù)雜,這里就不介紹了。
小結(jié) 命令git tag <name>用于新建一個(gè)標(biāo)簽,默認(rèn)為HEAD,也可以指定一個(gè)commit id; git tag -a <tagname> -m "blablabla..."可以指定標(biāo)簽信息; git tag -s <tagname> -m "blablabla..."可以用PGP簽名標(biāo)簽; 命令git tag可以查看所有標(biāo)簽。
18.操作標(biāo)簽 如果標(biāo)簽打錯(cuò)了,也可以刪除: $ git tag -d v0.1 Deleted tag 'v0.1' (was e078af9) 因?yàn)閯?chuàng)建的標(biāo)簽都只存儲(chǔ)在本地,不會(huì)自動(dòng)推送到遠(yuǎn)程。所以,打錯(cuò)的標(biāo)簽可以在本地安全刪除。
如果要推送某個(gè)標(biāo)簽到遠(yuǎn)程,使用命令git push origin <tagname>: $ git push origin v1.0 Total 0 (delta 0), reused 0 (delta 0) To git@github.com:michaelliao/learngit.git * [new tag] v1.0 -> v1.0 或者,一次性推送全部尚未推送到遠(yuǎn)程的本地標(biāo)簽: $ git push origin --tags Counting objects: 1, done. Writing objects: 100% (1/1), 554 bytes, done. Total 1 (delta 0), reused 0 (delta 0) To git@github.com:michaelliao/learngit.git * [new tag] v0.2 -> v0.2 * [new tag] v0.9 -> v0.9 如果標(biāo)簽已經(jīng)推送到遠(yuǎn)程,要?jiǎng)h除遠(yuǎn)程標(biāo)簽就麻煩一點(diǎn),先從本地刪除: $ git tag -d v0.9 Deleted tag 'v0.9' (was 6224937) 然后,從遠(yuǎn)程刪除。刪除命令也是push,但是格式如下: $ git push origin :refs/tags/v0.9 To git@github.com:michaelliao/learngit.git - [deleted] v0.9 要看看是否真的從遠(yuǎn)程庫(kù)刪除了標(biāo)簽,可以登陸GitHub查看。
小結(jié) 命令git push origin <tagname>可以推送一個(gè)本地標(biāo)簽; 命令git push origin --tags可以推送全部未推送過(guò)的本地標(biāo)簽; 命令git tag -d <tagname>可以刪除一個(gè)本地標(biāo)簽; 命令git push origin :refs/tags/<tagname>可以刪除一個(gè)遠(yuǎn)程標(biāo)簽。
19.使用GitHub 我們一直用GitHub作為免費(fèi)的遠(yuǎn)程倉(cāng)庫(kù),如果是個(gè)人的開源項(xiàng)目,放到GitHub上是完全沒(méi)有問(wèn)題的。其實(shí)GitHub還是一個(gè)開源協(xié)作社區(qū),通過(guò)GitHub,既可以讓別人參與你的開源項(xiàng)目,也可以參與別人的開源項(xiàng)目。
在GitHub出現(xiàn)以前,開源項(xiàng)目開源容易,但讓廣大人民群眾參與進(jìn)來(lái)比較困難,因?yàn)橐獏⑴c,就要提交代碼,而給每個(gè)想提交代碼的群眾都開一個(gè)賬號(hào)那是不現(xiàn)實(shí)的,因此,群眾也僅限于報(bào)個(gè)bug,即使能改掉bug,也只能把diff文件用郵件發(fā)過(guò)去,很不方便。
但是在GitHub上,利用Git極其強(qiáng)大的克隆和分支功能,廣大人民群眾真正可以第一次自由參與各種開源項(xiàng)目了。
如何參與一個(gè)開源項(xiàng)目呢?比如人氣極高的bootstrap項(xiàng)目,這是一個(gè)非常強(qiáng)大的CSS框架,你可以訪問(wèn)它的項(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)闆](méi)有權(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就不一定了。
如果你沒(méi)能力修改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ì)視心情而定是否接受。
小結(jié) 在GitHub上,可以任意Fork開源倉(cāng)庫(kù); 自己擁有Fork后的倉(cāng)庫(kù)的讀寫權(quán)限; 可以推送pull request給官方倉(cāng)庫(kù)來(lái)貢獻(xiàn)代碼。
20.自定義GIT 在安裝Git一節(jié)中,我們已經(jīng)配置了user.name和user.email,實(shí)際上,Git還有很多可配置項(xiàng)。 比如,讓Git顯示顏色,會(huì)讓命令輸出看起來(lái)更醒目: $ git config --global color.ui true 這樣,Git會(huì)適當(dāng)?shù)仫@示不同的顏色,比如git status命令: git-color 文件名就會(huì)標(biāo)上顏色。 我們?cè)诤竺孢€會(huì)介紹如何更好地配置Git,以便讓你的工作更高效。
21.忽略特殊文件 有些時(shí)候,你必須把某些文件放到Git工作目錄中,但又不能提交它們,比如保存了數(shù)據(jù)庫(kù)密碼的配置文件啦,等等,每次git status都會(huì)顯示Untracked files ...,有強(qiáng)迫癥的童鞋心里肯定不爽。
好在Git考慮到了大家的感受,這個(gè)問(wèn)題解決起來(lái)也很簡(jiǎn)單,在Git工作區(qū)的根目錄下創(chuàng)建一個(gè)特殊的.gitignore文件,然后把要忽略的文件名填進(jìn)去,Git就會(huì)自動(dòng)忽略這些文件。
不需要從頭寫.gitignore文件,GitHub已經(jīng)為我們準(zhǔn)備了各種配置文件,只需要組合一下就可以使用了。所有配置文件可以直接在線瀏覽:https://github.com/github/gitignore
忽略文件的原則是: 忽略操作系統(tǒng)自動(dòng)生成的文件,比如縮略圖等; 忽略編譯生成的中間文件、可執(zhí)行文件等,也就是如果一個(gè)文件是通過(guò)另一個(gè)文件自動(dòng)生成的,那自動(dòng)生成的文件就沒(méi)必要放進(jìn)版本庫(kù),比如Java編譯產(chǎn)生的.class文件; 忽略你自己的帶有敏感信息的配置文件,比如存放口令的配置文件。
舉個(gè)例子: 假設(shè)你在Windows下進(jìn)行Python開發(fā),Windows會(huì)自動(dòng)在有圖片的目錄下生成隱藏的縮略圖文件,如果有自定義目錄,目錄下就會(huì)有Desktop.ini文件,因此你需要忽略Windows自動(dòng)生成的垃圾文件: # Windows: Thumbs.db ehthumbs.db Desktop.ini 然后,繼續(xù)忽略Python編譯產(chǎn)生的.pyc、.pyo、dist等文件或目錄: # Python: *.py[cod] *.so *.egg *.egg-info dist build 加上你自己定義的文件,最終得到一個(gè)完整的.gitignore文件,內(nèi)容如下: # Windows: Thumbs.db ehthumbs.db Desktop.ini
# Python: *.py[cod] *.so *.egg *.egg-info dist build
# My configurations: db.ini deploy_key_rsa 最后一步就是把.gitignore也提交到Git,就完成了!當(dāng)然檢驗(yàn).gitignore的標(biāo)準(zhǔn)是git status命令是不是說(shuō)working directory clean。
使用Windows的童鞋注意了,如果你在資源管理器里新建一個(gè).gitignore文件,它會(huì)非常弱智地提示你必須輸入文件名,但是在文本編輯器里“保存”或者“另存為”就可以把文件保存為.gitignore了。
有些時(shí)候,你想添加一個(gè)文件到Git,但發(fā)現(xiàn)添加不了,原因是這個(gè)文件被.gitignore忽略了: $ git add App.class The following paths are ignored by one of your .gitignore files: App.class Use -f if you really want to add them. 如果你確實(shí)想添加該文件,可以用-f強(qiáng)制添加到Git: $ git add -f App.class 或者你發(fā)現(xiàn),可能是.gitignore寫得有問(wèn)題,需要找出來(lái)到底哪個(gè)規(guī)則寫錯(cuò)了,可以用git check-ignore命令檢查: $ git check-ignore -v App.class .gitignore:3:*.class App.class Git會(huì)告訴我們,.gitignore的第3行規(guī)則忽略了該文件,于是我們就可以知道應(yīng)該修訂哪個(gè)規(guī)則。
小結(jié) 忽略某些文件時(shí),需要編寫.gitignore; .gitignore文件本身要放到版本庫(kù)里,并且可以對(duì).gitignore做版本管理!
22.配置別名 有沒(méi)有經(jīng)常敲錯(cuò)命令?比如git status?status這個(gè)單詞真心不好記。 如果敲git st就表示git status那就簡(jiǎn)單多了,當(dāng)然這種偷懶的辦法我們是極力贊成的。 我們只需要敲一行命令,告訴Git,以后st就表示status: $ git config --global alias.st status 好了,現(xiàn)在敲git st看看效果。
當(dāng)然還有別的命令可以簡(jiǎn)寫,很多人都用co表示checkout,ci表示commit,br表示branch: $ git config --global alias.co checkout $ git config --global alias.ci commit $ git config --global alias.br branch 以后提交就可以簡(jiǎn)寫成: $ git ci -m "bala bala bala..." --global參數(shù)是全局參數(shù),也就是這些命令在這臺(tái)電腦的所有Git倉(cāng)庫(kù)下都有用。
在撤銷修改一節(jié)中,我們知道,命令git reset HEAD file可以把暫存區(qū)的修改撤銷掉(unstage),重新放回工作區(qū)。既然是一個(gè)unstage操作,就可以配置一個(gè)unstage別名: $ git config --global alias.unstage 'reset HEAD' 當(dāng)你敲入命令: $ git unstage test.py 實(shí)際上Git執(zhí)行的是: $ git reset HEAD test.py 配置一個(gè)git last,讓其顯示最后一次提交信息: $ git config --global alias.last 'log -1' 這樣,用git last就能顯示最近一次的提交: $ git last commit adca45d317e6d8a4b23f9811c3d7b7f0f180bfe2 Merge: bd6ae48 291bea8 Author: Michael Liao <askxuefeng@gmail.com> Date: Thu Aug 22 22:49:22 2013 +0800 merge & fix hello.py 甚至還有人喪心病狂地把lg配置成了: git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit" 來(lái)看看git lg的效果: git-lg 為什么不早點(diǎn)告訴我?別激動(dòng),咱不是為了多記幾個(gè)英文單詞嘛!
配置文件 配置Git的時(shí)候,加上--global是針對(duì)當(dāng)前用戶起作用的,如果不加,那只針對(duì)當(dāng)前的倉(cāng)庫(kù)起作用。 配置文件放哪了?每個(gè)倉(cāng)庫(kù)的Git配置文件都放在.git/config文件中: $ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true precomposeunicode = true [remote "origin"] url = git@github.com:michaelliao/learngit.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [alias] last = log -1 別名就在[alias]后面,要?jiǎng)h除別名,直接把對(duì)應(yīng)的行刪掉即可。 而當(dāng)前用戶的Git配置文件放在用戶主目錄下的一個(gè)隱藏文件.gitconfig中: $ cat .gitconfig [alias] co = checkout ci = commit br = branch st = status [user] name = Your Name email = your@email.com 配置別名也可以直接修改這個(gè)文件,如果改錯(cuò)了,可以刪掉文件重新通過(guò)命令配置。
小結(jié) 給Git配置好別名,就可以輸入命令時(shí)偷個(gè)懶。我們鼓勵(lì)偷懶。
23.搭建Git服務(wù)器 在遠(yuǎn)程倉(cāng)庫(kù)一節(jié)中,我們講了遠(yuǎn)程倉(cāng)庫(kù)實(shí)際上和本地倉(cāng)庫(kù)沒(méi)啥不同,純粹為了7x24小時(shí)開機(jī)并交換大家的修改。 GitHub就是一個(gè)免費(fèi)托管開源代碼的遠(yuǎn)程倉(cāng)庫(kù)。但是對(duì)于某些視源代碼如生命的商業(yè)公司來(lái)說(shuō),既不想公開源代碼,又舍不得給GitHub交保護(hù)費(fèi),那就只能自己搭建一臺(tái)Git服務(wù)器作為私有倉(cāng)庫(kù)使用。
搭建Git服務(wù)器需要準(zhǔn)備一臺(tái)運(yùn)行Linux的機(jī)器,強(qiáng)烈推薦用Ubuntu或Debian,這樣,通過(guò)幾條簡(jiǎn)單的apt命令就可以完成安裝。
假設(shè)你已經(jīng)有sudo權(quán)限的用戶賬號(hào),下面,正式開始安裝。 第一步,安裝git: $ sudo apt-get install git 第二步,創(chuàng)建一個(gè)git用戶,用來(lái)運(yùn)行g(shù)it服務(wù): $ sudo adduser git 第三步,創(chuàng)建證書登錄: 收集所有需要登錄的用戶的公鑰,就是他們自己的id_rsa.pub文件,把所有公鑰導(dǎo)入到/home/git/.ssh/authorized_keys文件里,一行一個(gè)。 第四步,初始化Git倉(cāng)庫(kù): 先選定一個(gè)目錄作為Git倉(cāng)庫(kù),假定是/srv/sample.git,在/srv目錄下輸入命令: $ sudo git init --bare sample.git Git就會(huì)創(chuàng)建一個(gè)裸倉(cāng)庫(kù),裸倉(cāng)庫(kù)沒(méi)有工作區(qū),因?yàn)榉?wù)器上的Git倉(cāng)庫(kù)純粹是為了共享,所以不讓用戶直接登錄到服務(wù)器上去改工作區(qū),并且服務(wù)器上的Git倉(cāng)庫(kù)通常都以.git結(jié)尾。然后,把owner改為git: $ sudo chown -R git:git sample.git 第五步,禁用shell登錄: 出于安全考慮,第二步創(chuàng)建的git用戶不允許登錄shell,這可以通過(guò)編輯/etc/passwd文件完成。找到類似下面的一行: git:x:1001:1001:,,,:/home/git:/bin/bash 改為: git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell 這樣,git用戶可以正常通過(guò)ssh使用git,但無(wú)法登錄shell,因?yàn)槲覀優(yōu)間it用戶指定的git-shell每次一登錄就自動(dòng)退出。 第六步,克隆遠(yuǎn)程倉(cāng)庫(kù): 現(xiàn)在,可以通過(guò)git clone命令克隆遠(yuǎn)程倉(cāng)庫(kù)了,在各自的電腦上運(yùn)行: $ git clone git@server:/srv/sample.git Cloning into 'sample'... warning: You appear to have cloned an empty repository. 剩下的推送就簡(jiǎn)單了。
管理公鑰 如果團(tuán)隊(duì)很小,把每個(gè)人的公鑰收集起來(lái)放到服務(wù)器的/home/git/.ssh/authorized_keys文件里就是可行的。如果團(tuán)隊(duì)有幾百號(hào)人,就沒(méi)法這么玩了,這時(shí),可以用Gitosis來(lái)管理公鑰。 這里我們不介紹怎么玩Gitosis了,幾百號(hào)人的團(tuán)隊(duì)基本都在500強(qiáng)了,相信找個(gè)高水平的Linux管理員問(wèn)題不大。
管理權(quán)限 有很多不但視源代碼如生命,而且視員工為竊賊的公司,會(huì)在版本控制系統(tǒng)里設(shè)置一套完善的權(quán)限控制,每個(gè)人是否有讀寫權(quán)限會(huì)精確到每個(gè)分支甚至每個(gè)目錄下。因?yàn)镚it是為L(zhǎng)inux源代碼托管而開發(fā)的,所以Git也繼承了開源社區(qū)的精神,不支持權(quán)限控制。不過(guò),因?yàn)镚it支持鉤子(hook),所以,可以在服務(wù)器端編寫一系列腳本來(lái)控制提交等操作,達(dá)到權(quán)限控制的目的。Gitolite就是這個(gè)工具。 這里我們也不介紹Gitolite了,不要把有限的生命浪費(fèi)到權(quán)限斗爭(zhēng)中。
小結(jié) 搭建Git服務(wù)器非常簡(jiǎn)單,通常10分鐘即可完成; 要方便管理公鑰,用Gitosis; 要像SVN那樣變態(tài)地控制權(quán)限,用Gitolite。
|