Git教程

時間 2019-11-13

標籤 git 教程欄目 Git 简体版

原文原文鏈接

--fast-version-controljavascript

史上最淺顯易懂的Git教程！php

爲何要編寫這個教程？由於我在學習Git的過程當中，買過書，也在網上Google了一堆Git相關的文章和教程，但使人失望的是，這些教程不是可貴使人髮指，就是簡單得一筆帶過，或者，只支離破碎地介紹Git的某幾個命令，還有直接從Git手冊粘貼幫助文檔的，總之，初學者很難找到一個由淺入深，學完後能馬上上手的Git教程。css

既然號稱史上最淺顯易懂的Git教程，那這個教程有什麼讓你怦然心動的特色呢？html

首先，本教程絕對面向初學者，沒有接觸過版本控制概念的讀者也能夠輕鬆入門，沒必要擔憂起步難度；html5

其次，本教程實用性超強，邊學邊練，一點也不以爲枯燥。並且，你所學的Git命令是「充分且必要」的，掌握了這些東西，你就能夠經過Git輕鬆地完成你的工做。java

文字+圖片還看不明白？有視頻！！！python

本教程只會讓你成爲Git用戶，不會讓你成爲Git專家。不少Git命令只有那些專家才明白（事實上我也不明白，由於我不是Git專家），但我保證這些命令可能你一生都不會用到。既然Git是一個工具，就不必把時間浪費在那些「高級」但幾乎永遠不會用到的命令上。一旦你真的非用不可了，到時候再自行Google或者請教專家也未遲。git

若是你是一個開發人員，想用上這個世界上目前最早進的分佈式版本控制系統，那麼，趕快開始學習吧！github

1 Git簡介

Git是什麼？sql

Git是目前世界上最早進的分佈式版本控制系統（沒有之一）。

Git有什麼特色？簡單來講就是：高端大氣上檔次！

那什麼是版本控制系統？

若是你用Microsoft Word寫過長篇大論，那你必定有這樣的經歷：

想刪除一個段落，又怕未來想恢復找不回來怎麼辦？有辦法，先把當前文件「另存爲……」一個新的Word文件，再接着改，改到必定程度，再「另存爲……」一個新文件，這樣一直改下去，最後你的Word文檔變成了這樣：

過了一週，你想找回被刪除的文字，可是已經記不清刪除前保存在哪一個文件裏了，只好一個一個文件去找，真麻煩。

看着一堆亂七八糟的文件，想保留最新的一個，而後把其餘的刪掉，又怕哪天會用上，還不敢刪，真鬱悶。

更要命的是，有些部分須要你的財務同事幫助填寫，因而你把文件Copy到U盤裏給她（也可能經過Email發送一份給她），而後，你繼續修改Word文件。一天後，同事再把Word文件傳給你，此時，你必須想一想，發給她以後到你收到她的文件期間，你做了哪些改動，得把你的改動和她的部分合並，真困難。

因而你想，若是有一個軟件，不但能自動幫我記錄每次文件的改動，還可讓同事協做編輯，這樣就不用本身管理一堆相似的文件了，也不須要把文件傳來傳去。若是想查看某次改動，只須要在軟件裏瞄一眼就能夠，豈不是很方便？

這個軟件用起來就應該像這個樣子，能記錄每次文件的改動：

版本	文件名	用戶	說明	日期
1	service.doc	張三	刪除了軟件服務條款5	7/12 10:38
2	service.doc	張三	增長了License人數限制	7/12 18:09
3	service.doc	李四	財務部門調整了合同金額	7/13 9:51
4	service.doc	張三	延長了免費升級週期	7/14 15:17

這樣，你就結束了手動管理多個「版本」的史前時代，進入到版本控制的20世紀。

1.1 Git的誕生

不少人都知道，Linus在1991年建立了開源的Linux，今後，Linux系統不斷髮展，已經成爲最大的服務器系統軟件了。

Linus雖然建立了Linux，但Linux的壯大是靠全世界熱心的志願者參與的，這麼多人在世界各地爲Linux編寫代碼，那Linux的代碼是如何管理的呢？

事實是，在2002年之前，世界各地的志願者把源代碼文件經過diff的方式發給Linus，而後由Linus本人經過手工方式合併代碼！

你也許會想，爲何Linus不把Linux代碼放到版本控制系統裏呢？不是有CVS、SVN這些免費的版本控制系統嗎？由於Linus堅決地反對CVS和SVN，這些集中式的版本控制系統不但速度慢，並且必須聯網才能使用。有一些商用的版本控制系統，雖然比CVS、SVN好用，但那是付費的，和Linux的開源精神不符。

不過，到了2002年，Linux系統已經發展了十年了，代碼庫之大讓Linus很難繼續經過手工方式管理了，社區的弟兄們也對這種方式表達了強烈不滿，因而Linus選擇了一個商業的版本控制系統BitKeeper，BitKeeper的東家BitMover公司出於人道主義精神，受權Linux社區無償使用這個版本控制系統。

安定團結的大好局面在2005年就被打破了，緣由是Linux社區牛人彙集，難免沾染了一些梁山好漢的江湖習氣。開發Samba的Andrew試圖破解BitKeeper的協議（這麼幹的其實也不僅他一個），被BitMover公司發現了（監控工做作得不錯！），因而BitMover公司怒了，要收回Linux社區的無償使用權。

Linus能夠向BitMover公司道個歉，保證之後嚴格管教弟兄們，嗯，這是不可能的。實際狀況是這樣的：

Linus花了兩週時間本身用C寫了一個分佈式版本控制系統，這就是Git！一個月以內，Linux系統的源碼已經由Git管理了！牛是怎麼定義的呢？你們能夠體會一下。

Git迅速成爲最流行的分佈式版本控制系統，尤爲是2008年，GitHub網站上線了，它爲開源項目免費提供Git存儲，無數開源項目開始遷移至GitHub，包括jQuery，PHP，Ruby等等。

歷史就是這麼偶然，若是不是當年BitMover公司威脅Linux社區，可能如今咱們就沒有免費而超級好用的Git了。

1.2 集中式vs分佈式

Linus一直痛恨的CVS及SVN都是集中式的版本控制系統，而Git是分佈式版本控制系統，集中式和分佈式版本控制系統有什麼區別呢？

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

集中式版本控制系統最大的毛病就是必須聯網才能工做，若是在局域網內還好，帶寬夠大，速度夠快，可若是在互聯網上，遇到網速慢的話，可能提交一個10M的文件就須要5分鐘，這還不得把人給憋死啊。

那分佈式版本控制系統與集中式版本控制系統有何不一樣呢？首先，分佈式版本控制系統根本沒有「中央服務器」，每一個人的電腦上都是一個完整的版本庫，這樣，你工做的時候，就不須要聯網了，由於版本庫就在你本身的電腦上。既然每一個人電腦上都有一個完整的版本庫，那多我的如何協做呢？比方說你在本身電腦上改了文件A，你的同事也在他的電腦上改了文件A，這時，大家倆之間只需把各自的修改推送給對方，就能夠互相看到對方的修改了。

和集中式版本控制系統相比，分佈式版本控制系統的安全性要高不少，由於每一個人電腦裏都有完整的版本庫，某一我的的電腦壞掉了沒關係，隨便從其餘人那裏複製一個就能夠了。而集中式版本控制系統的中央服務器要是出了問題，全部人都無法幹活了。

在實際使用分佈式版本控制系統的時候，其實不多在兩人之間的電腦上推送版本庫的修改，由於可能大家倆不在一個局域網內，兩臺電腦互相訪問不了，也可能今天你的同事病了，他的電腦壓根沒有開機。所以，分佈式版本控制系統一般也有一臺充當「中央服務器」的電腦，但這個服務器的做用僅僅是用來方便「交換」你們的修改，沒有它你們也同樣幹活，只是交換修改不方便而已。

固然，Git的優點不單是沒必要聯網這麼簡單，後面咱們還會看到Git極其強大的分支管理，把SVN等遠遠拋在了後面。

CVS做爲最先的開源並且免費的集中式版本控制系統，直到如今還有很多人在用。因爲CVS自身設計的問題，會形成提交文件不完整，版本庫莫名其妙損壞的狀況。一樣是開源並且免費的SVN修正了CVS的一些穩定性問題，是目前用得最多的集中式版本庫控制系統。

除了免費的外，還有收費的集中式版本控制系統，好比IBM的ClearCase（之前是Rational公司的，被IBM收購了），特色是安裝比Windows還大，運行比蝸牛還慢，能用ClearCase的通常是世界500強，他們有個共同的特色是財大氣粗，或者人傻錢多。

微軟本身也有一個集中式版本控制系統叫VSS，集成在Visual Studio中。因爲其反人類的設計，連微軟本身都很差意思用了。

分佈式版本控制系統除了Git以及促使Git誕生的BitKeeper外，還有相似Git的Mercurial和Bazaar等。這些分佈式版本控制系統各有特色，但最快、最簡單也最流行的依然是Git！

2 安裝Git

最先Git是在Linux上開發的，很長一段時間內，Git也只能在Linux和Unix系統上跑。不過，慢慢地有人把它移植到了Windows上。如今，Git能夠在Linux、Unix、Mac和Windows這幾大平臺上正常運行了。

要使用Git，第一步固然是安裝Git了。根據你當前使用的平臺來閱讀下面的文字：

2.1 在Linux上安裝Git

首先，你能夠試着輸入git，看看系統有沒有安裝Git：

$ git
The program 'git' is currently not installed. You can install it by typing:
sudo apt-get install git

像上面的命令，有不少Linux會友好地告訴你Git沒有安裝，還會告訴你如何安裝Git。

若是你碰巧用Debian或Ubuntu Linux，經過一條sudo apt-get install git就能夠直接完成Git的安裝，很是簡單。

老一點的Debian或Ubuntu Linux，要把命令改成sudo apt-get install git-core，由於之前有個軟件也叫GIT（GNU Interactive Tools），結果Git就只能叫git-core了。因爲Git名氣實在太大，後來就把GNU Interactive Tools改爲gnuit，git-core正式改成git。

若是是其餘Linux版本，能夠直接經過源碼安裝。先從Git官網下載源碼，而後解壓，依次輸入：./config，make，sudo make install這幾個命令安裝就行了。

2.2 在Mac OS X上安裝Git

若是你正在使用Mac作開發，有兩種安裝Git的方法。

一是安裝homebrew，而後經過homebrew安裝Git，具體方法請參考homebrew的文檔：http://brew.sh/。

第二種方法更簡單，也是推薦的方法，就是直接從AppStore安裝Xcode，Xcode集成了Git，不過默認沒有安裝，你須要運行Xcode，選擇菜單「Xcode」->「Preferences」，在彈出窗口中找到「Downloads」，選擇「Command Line Tools」，點「Install」就能夠完成安裝了。

Xcode是Apple官方IDE，功能很是強大，是開發Mac和iOS App的必選裝備，並且是免費的！

2.3 在Windows上安裝Git

在Windows上使用Git，能夠從Git官網直接下載安裝程序，（網速慢的同窗請移步國內鏡像），而後按默認選項安裝便可。

安裝完成後，在開始菜單裏找到「Git」->「Git Bash」，蹦出一個相似命令行窗口的東西，就說明Git安裝成功！

安裝完成後，還須要最後一步設置，在命令行輸入：

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"

由於Git是分佈式版本控制系統，因此，每一個機器都必須自報家門：你的名字和Email地址。你也許會擔憂，若是有人故意冒充別人怎麼辦？這個沒必要擔憂，首先咱們相信你們都是善良無知的羣衆，其次，真的有冒充的也是有辦法可查的。

注意git config命令的--global參數，用了這個參數，表示你這臺機器上全部的Git倉庫都會使用這個配置，固然也能夠對某個倉庫指定不一樣的用戶名和Email地址。

3 建立版本庫

什麼是版本庫呢？版本庫又名倉庫，英文名repository，你能夠簡單理解成一個目錄，這個目錄裏面的全部文件均可以被Git管理起來，每一個文件的修改、刪除，Git都能跟蹤，以便任什麼時候刻均可以追蹤歷史，或者在未來某個時刻能夠「還原」。

因此，建立一個版本庫很是簡單，首先，選擇一個合適的地方，建立一個空目錄：

$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit

pwd命令用於顯示當前目錄。在個人Mac上，這個倉庫位於/Users/michael/learngit。

若是你使用Windows系統，爲了不遇到各類莫名其妙的問題，請確保目錄名（包括父目錄）不包含中文。

第二步，經過git init命令把這個目錄變成Git能夠管理的倉庫：

$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/

瞬間Git就把倉庫建好了，並且告訴你是一個空的倉庫（empty Git repository），細心的讀者能夠發現當前目錄下多了一個.git的目錄，這個目錄是Git來跟蹤管理版本庫的，沒事千萬不要手動修改這個目錄裏面的文件，否則改亂了，就把Git倉庫給破壞了。

若是你沒有看到.git目錄，那是由於這個目錄默認是隱藏的，用ls -ah命令就能夠看見。

也不必定必須在空目錄下建立Git倉庫，選擇一個已經有東西的目錄也是能夠的。不過，不建議你使用本身正在開發的公司項目來學習Git，不然形成的一切後果概不負責。

3.1 把文件添加到版本庫

首先這裏再明確一下，全部的版本控制系統，其實只能跟蹤文本文件的改動，好比TXT文件，網頁，全部的程序代碼等等，Git也不例外。版本控制系統能夠告訴你每次的改動，好比在第5行加了一個單詞「Linux」，在第8行刪了一個單詞「Windows」。而圖片、視頻這些二進制文件，雖然也能由版本控制系統管理，但無法跟蹤文件的變化，只能把二進制文件每次改動串起來，也就是隻知道圖片從100KB改爲了120KB，但到底改了啥，版本控制系統不知道，也無法知道。

不幸的是，Microsoft的Word格式是二進制格式，所以，版本控制系統是無法跟蹤Word文件的改動的，前面咱們舉的例子只是爲了演示，若是要真正使用版本控制系統，就要以純文本方式編寫文件。

由於文本是有編碼的，好比中文有經常使用的GBK編碼，日文有Shift_JIS編碼，若是沒有歷史遺留問題，強烈建議使用標準的UTF-8編碼，全部語言使用同一種編碼，既沒有衝突，又被全部平臺所支持。

使用Windows的童鞋要特別注意：

千萬不要使用Windows自帶的記事本編輯任何文本文件。緣由是Microsoft開發記事本的團隊使用了一個很是弱智的行爲來保存UTF-8編碼的文件，他們自做聰明地在每一個文件開頭添加了0xefbbbf（十六進制）的字符，你會遇到不少難以想象的問題，好比，網頁第一行可能會顯示一個「?」，明明正確的程序一編譯就報語法錯誤，等等，都是由記事本的弱智行爲帶來的。建議你下載Notepad++代替記事本，不但功能強大，並且免費！記得把Notepad++的默認編碼設置爲UTF-8 without BOM便可：

言歸正傳，如今咱們編寫一個readme.txt文件，內容以下：

Git is a version control system.
Git is free software.

必定要放到learngit目錄下（子目錄也行），由於這是一個Git倉庫，放到其餘地方Git再厲害也找不到這個文件。

和把大象放到冰箱須要3步相比，把一個文件放到Git倉庫只須要兩步。

第一步，用命令git add告訴Git，把文件添加到倉庫：

$ git add readme.txt

執行上面的命令，沒有任何顯示，這就對了，Unix的哲學是「沒有消息就是好消息」，說明添加成功。

第二步，用命令git commit告訴Git，把文件提交到倉庫：

$ git commit -m "wrote a readme file"
[master (root-commit) eaadf4e] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt

簡單解釋一下git commit命令，-m後面輸入的是本次提交的說明，能夠輸入任意內容，固然最好是有意義的，這樣你就能從歷史記錄裏方便地找到改動記錄。

嫌麻煩不想輸入-m "xxx"行不行？確實有辦法能夠這麼幹，可是強烈不建議你這麼幹，由於輸入說明對本身對別人閱讀都很重要。實在不想輸入說明的童鞋請自行Google，我不告訴你這個參數。

git commit命令執行成功後會告訴你，1 file changed：1個文件被改動（咱們新添加的readme.txt文件）；2 insertions：插入了兩行內容（readme.txt有兩行內容）。

爲何Git添加文件須要add，commit一共兩步呢？由於commit能夠一次提交不少文件，因此你能夠屢次add不一樣的文件，好比：

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

3.2 小結

如今總結一下今天學的兩點內容：

初始化一個Git倉庫，使用git init命令。

添加文件到Git倉庫，分兩步：

使用命令git add <file>，注意，可反覆屢次使用，添加多個文件；
使用命令git commit -m <message>，完成。

4 時光機穿梭

咱們已經成功地添加並提交了一個readme.txt文件，如今，是時候繼續工做了，因而，咱們繼續修改readme.txt文件，改爲以下內容：

Git is a distributed version control system. Git is free software.

如今，運行git status命令看看結果：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")

git status命令可讓咱們時刻掌握倉庫當前的狀態，上面的命令輸出告訴咱們，readme.txt被修改過了，但尚未準備提交的修改。

雖然Git告訴咱們readme.txt被修改了，但若是能看看具體修改了什麼內容，天然是很好的。好比你休假兩週從國外回來，第一天上班時，已經記不清上次怎麼修改的readme.txt，因此，須要用git diff這個命令看看：

$ git diff readme.txt 
diff --git a/readme.txt b/readme.txt
index 46d49bf..9247db6 100644 --- a/readme.txt +++ b/readme.txt @@ -1,2 +1,2 @@ -Git is a version control system. +Git is a distributed version control system. Git is free software.

git diff顧名思義就是查看difference，顯示的格式正是Unix通用的diff格式，能夠從上面的命令輸出看到，咱們在第一行添加了一個distributed單詞。

知道了對readme.txt做了什麼修改後，再把它提交到倉庫就放心多了，提交修改和提交新文件是同樣的兩步，第一步是git add：

$ git add readme.txt

一樣沒有任何輸出。在執行第二步git commit以前，咱們再運行git status看看當前倉庫的狀態：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage) modified: readme.txt

git status告訴咱們，將要被提交的修改包括readme.txt，下一步，就能夠放心地提交了：

$ git commit -m "add distributed" [master e475afc] add distributed 1 file changed, 1 insertion(+), 1 deletion(-)

提交後，咱們再用git status命令看看倉庫的當前狀態：

$ git status
On branch master
nothing to commit, working tree clean

Git告訴咱們當前沒有須要提交的修改，並且，工做目錄是乾淨（working tree clean）的。

小結

要隨時掌握工做區的狀態，使用git status命令。
若是git status告訴你有文件被修改過，用git diff能夠查看修改內容。

4.1 版本回退

如今，你已經學會了修改文件，而後把修改提交到Git版本庫，如今，再練習一次，修改readme.txt文件以下：

Git is a distributed version control system. Git is free software distributed under the GPL.

而後嘗試提交：

$ git add readme.txt $ git commit -m "append GPL" [master 1094adb] append GPL 1 file changed, 1 insertion(+), 1 deletion(-)

像這樣，你不斷對文件進行修改，而後不斷提交修改到版本庫裏，就比如玩RPG遊戲時，每經過一關就會自動把遊戲狀態存盤，若是某一關沒過去，你還能夠選擇讀取前一關的狀態。有些時候，在打Boss以前，你會手動存盤，以便萬一打Boss失敗了，能夠從最近的地方從新開始。Git也是同樣，每當你以爲文件修改到必定程度的時候，就能夠「保存一個快照」，這個快照在Git中被稱爲commit。一旦你把文件改亂了，或者誤刪了文件，還能夠從最近的一個commit恢復，而後繼續工做，而不是把幾個月的工做成果所有丟失。

如今，咱們回顧一下readme.txt文件一共有幾個版本被提交到Git倉庫裏了：

版本1：wrote a readme file

Git is a version control system. Git is free software.

版本2：add distributed

Git is a distributed version control system. Git is free software.

版本3：append GPL

Git is a distributed version control system. Git is free software distributed under the GPL.

固然了，在實際工做中，咱們腦子裏怎麼可能記得一個幾千行的文件每次都改了什麼內容，否則要版本控制系統幹什麼。版本控制系統確定有某個命令能夠告訴咱們歷史記錄，在Git中，咱們用git log命令查看：

$ git log
commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master)
Author: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 21:06:15 2018 +0800 append GPL commit e475afc93c209a690c39c13a46716e8fa000c366 Author: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 21:03:36 2018 +0800 add distributed commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 Author: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 20:59:18 2018 +0800 wrote a readme file

git log命令顯示從最近到最遠的提交日誌，咱們能夠看到3次提交，最近的一次是append GPL，上一次是add distributed，最先的一次是wrote a readme file。

若是嫌輸出信息太多，看得眼花繚亂的，能夠試試加上--pretty=oneline參數：

$ git log --pretty=oneline 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append GPL e475afc93c209a690c39c13a46716e8fa000c366 add distributed eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file

須要友情提示的是，你看到的一大串相似1094adb...的是commit id（版本號），和SVN不同，Git的commit id不是1，2，3……遞增的數字，而是一個SHA1計算出來的一個很是大的數字，用十六進制表示，並且你看到的commit id和個人確定不同，以你本身的爲準。爲何commit id須要用這麼一大串數字表示呢？由於Git是分佈式的版本控制系統，後面咱們還要研究多人在同一個版本庫裏工做，若是你們都用1，2，3……做爲版本號，那確定就衝突了。

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

好了，如今咱們啓動時光穿梭機，準備把readme.txt回退到上一個版本，也就是add distributed的那個版本，怎麼作呢？

首先，Git必須知道當前版本是哪一個版本，在Git中，用HEAD表示當前版本，也就是最新的提交1094adb...（注意個人提交ID和你的確定不同），上一個版本就是HEAD^，上上一個版本就是HEAD^^，固然往上100個版本寫100個^比較容易數不過來，因此寫成HEAD~100。

如今，咱們要把當前版本append GPL回退到上一個版本add distributed，就能夠使用git reset命令：

$ git reset --hard HEAD^ HEAD is now at e475afc add distributed

--hard參數有啥意義？這個後面再講，如今你先放心使用。

看看readme.txt的內容是否是版本add distributed：

$ cat readme.txt
Git is a distributed version control system. Git is free software.

果真被還原了。

還能夠繼續回退到上一個版本wrote a readme file，不過且慢，然咱們用git log再看看如今版本庫的狀態：

$ git log
commit e475afc93c209a690c39c13a46716e8fa000c366 (HEAD -> master)
Author: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 21:03:36 2018 +0800 add distributed commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 Author: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 20:59:18 2018 +0800 wrote a readme file

最新的那個版本append GPL已經看不到了！比如你從21世紀坐時光穿梭機來到了19世紀，想再回去已經回不去了，腫麼辦？

辦法其實仍是有的，只要上面的命令行窗口尚未被關掉，你就能夠順着往上找啊找啊，找到那個append GPL的commit id是1094adb...，因而就能夠指定回到將來的某個版本：

$ git reset --hard 1094a HEAD is now at 83b0afe append GPL

版本號不必寫全，前幾位就能夠了，Git會自動去找。固然也不能只寫前一兩位，由於Git可能會找到多個版本號，就沒法肯定是哪個了。

再當心翼翼地看看readme.txt的內容：

$ cat readme.txt
Git is a distributed version control system. Git is free software distributed under the GPL.

果真，我胡漢三又回來了。

Git的版本回退速度很是快，由於Git在內部有個指向當前版本的HEAD指針，當你回退版本的時候，Git僅僅是把HEAD從指向append GPL：

┌────┐
│HEAD│
└────┘
   │
   └──> ○ append GPL
        │
        ○ add distributed
        │
        ○ wrote a readme file

改成指向add distributed：

┌────┐
│HEAD│
└────┘
   │
   │    ○ append GPL
   │    │
   └──> ○ add distributed
        │
        ○ wrote a readme file

而後順便把工做區的文件更新了。因此你讓HEAD指向哪一個版本號，你就把當前版本定位在哪。

如今，你回退到了某個版本，關掉了電腦，次日早上就後悔了，想恢復到新版本怎麼辦？找不到新版本的commit id怎麼辦？

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

$ git reflog e475afc HEAD@{1}: reset: moving to HEAD^ 1094adb (HEAD -> master) HEAD@{2}: commit: append GPL e475afc HEAD@{3}: commit: add distributed eaadf4e HEAD@{4}: commit (initial): wrote a readme file

終於舒了口氣，從輸出可知，append GPL的commit id是1094adb，如今，你又能夠乘坐時光機回到將來了。

小結

如今總結一下：

HEAD指向的版本就是當前版本，所以，Git容許咱們在版本的歷史之間穿梭，使用命令git reset --hard commit_id。
穿梭前，用git log能夠查看提交歷史，以便肯定要回退到哪一個版本。
要重返將來，用git reflog查看命令歷史，以便肯定要回到將來的哪一個版本。

4.2 工做區和暫存區

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

先來看名詞解釋。

工做區（Working Directory）

就是你在電腦裏能看到的目錄，好比個人learngit文件夾就是一個工做區：

版本庫（Repository）

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

Git的版本庫裏存了不少東西，其中最重要的就是稱爲stage（或者叫index）的暫存區，還有Git爲咱們自動建立的第一個分支master，以及指向master的一個指針叫HEAD。

分支和HEAD的概念咱們之後再講。

前面講了咱們把文件往Git版本庫裏添加的時候，是分兩步執行的：

第一步是用git add把文件添加進去，實際上就是把文件修改添加到暫存區；

第二步是用git commit提交更改，實際上就是把暫存區的全部內容提交到當前分支。

由於咱們建立Git版本庫時，Git自動爲咱們建立了惟一一個master分支，因此，如今，git commit就是往master分支上提交更改。

你能夠簡單理解爲，須要提交的文件修改統統放到暫存區，而後，一次性提交暫存區的全部修改。

俗話說，實踐出真知。如今，咱們再練習一遍，先對readme.txt作個修改，好比加上一行內容：

Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage.

而後，在工做區新增一個LICENSE文本文件（內容隨便寫）。

先用git status查看一下狀態：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt Untracked files: (use "git add <file>..." to include in what will be committed) LICENSE no changes added to commit (use "git add" and/or "git commit -a")

Git很是清楚地告訴咱們，readme.txt被修改了，而LICENSE還歷來沒有被添加過，因此它的狀態是Untracked。

如今，使用兩次命令git add，把readme.txt和LICENSE都添加後，用git status再查看一下：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage) new file: LICENSE modified: readme.txt

如今，暫存區的狀態就變成這樣了：

因此，git add命令實際上就是把要提交的全部修改放到暫存區（Stage），而後，執行git commit就能夠一次性把暫存區的全部修改提交到分支。

$ git commit -m "understand how stage works" [master e43a48b] understand how stage works 2 files changed, 2 insertions(+) create mode 100644 LICENSE

一旦提交後，若是你又沒有對工做區作任何修改，那麼工做區就是「乾淨」的：

$ git status
On branch master
nothing to commit, working tree clean

如今版本庫變成了這樣，暫存區就沒有任何內容了：

小結

暫存區是Git很是重要的概念，弄明白了暫存區，就弄明白了Git的不少操做到底幹了什麼。

沒弄明白暫存區是怎麼回事的童鞋，請向上滾動頁面，再看一次。

4.3 管理修改

如今，假定你已經徹底掌握了暫存區的概念。下面，咱們要討論的就是，爲何Git比其餘版本控制系統設計得優秀，由於Git跟蹤並管理的是修改，而非文件。

你會問，什麼是修改？好比你新增了一行，這就是一個修改，刪除了一行，也是一個修改，更改了某些字符，也是一個修改，刪了一些又加了一些，也是一個修改，甚至建立一個新文件，也算一個修改。

爲何說Git管理的是修改，而不是文件呢？咱們仍是作實驗。第一步，對readme.txt作一個修改，好比加一行內容：

$ cat readme.txt
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.

而後，添加：

$ git add readme.txt $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: readme.txt #

而後，再修改readme.txt：

$ cat readme.txt 
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.

提交：

$ git commit -m "git tracks changes" [master 519219b] git tracks changes 1 file changed, 1 insertion(+)

提交後，再看看狀態：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")

咦，怎麼第二次的修改沒有被提交？

別激動，咱們回顧一下操做過程：

第一次修改 -> git add -> 第二次修改 -> git commit

你看，咱們前面講了，Git管理的是修改，當你用git add命令後，在工做區的第一次修改被放入暫存區，準備提交，可是，在工做區的第二次修改並無放入暫存區，因此，git commit只負責把暫存區的修改提交了，也就是第一次的修改被提交了，第二次的修改不會被提交。

提交後，用git diff HEAD -- readme.txt命令能夠查看工做區和版本庫裏面最新版本的區別：

$ git diff HEAD -- readme.txt 
diff --git a/readme.txt b/readme.txt
index 76d770f..a9c5755 100644 --- a/readme.txt +++ b/readme.txt @@ -1,4 +1,4 @@ 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. +Git tracks changes of files.

可見，第二次修改確實沒有被提交。

那怎麼提交第二次修改呢？你能夠繼續git add再git commit，也能夠彆着急提交第一次修改，先git add第二次修改，再git commit，就至關於把兩次修改合併後一塊提交了：

第一次修改 -> git add -> 第二次修改 -> git add -> git commit

好，如今，把第二次修改提交了，而後開始小結。

小結

如今，你又理解了Git是如何跟蹤修改的，每次修改，若是不用git add到暫存區，那就不會加入到commit中。

4.4 撤銷修改

天然，你是不會犯錯的。不過如今是凌晨兩點，你正在趕一份工做報告，你在readme.txt中添加了一行：

$ cat readme.txt
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. My stupid boss still prefers SVN.

在你準備提交前，一杯咖啡起了做用，你猛然發現了stupid boss可能會讓你丟掉這個月的獎金！

既然錯誤發現得很及時，就能夠很容易地糾正它。你能夠刪掉最後一行，手動把文件恢復到上一個版本的狀態。若是用git status查看一下：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")

你能夠發現，Git會告訴你，git checkout -- file能夠丟棄工做區的修改：

$ git checkout -- readme.txt

命令git checkout -- readme.txt意思就是，把readme.txt文件在工做區的修改所有撤銷，這裏有兩種狀況：

一種是readme.txt自修改後尚未被放到暫存區，如今，撤銷修改就回到和版本庫如出一轍的狀態；

一種是readme.txt已經添加到暫存區後，又做了修改，如今，撤銷修改就回到添加到暫存區後的狀態。

總之，就是讓這個文件回到最近一次git commit或git add時的狀態。

如今，看看readme.txt的文件內容：

$ cat readme.txt
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.

文件內容果真復原了。

git checkout -- file命令中的--很重要，沒有--，就變成了「切換到另外一個分支」的命令，咱們在後面的分支管理中會再次遇到git checkout命令。

如今假定是凌晨3點，你不但寫了一些胡話，還git add到暫存區了：

$ cat readme.txt 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. My stupid boss still prefers SVN. $ git add readme.txt

慶幸的是，在commit以前，你發現了這個問題。用git status查看一下，修改只是添加到了暫存區，尚未提交：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage) modified: readme.txt

Git一樣告訴咱們，用命令git reset HEAD <file>能夠把暫存區的修改撤銷掉（unstage），從新放回工做區：

$ git reset HEAD readme.txt Unstaged changes after reset: M readme.txt

git reset命令既能夠回退版本，也能夠把暫存區的修改回退到工做區。當咱們用HEAD時，表示最新的版本。

再用git status查看一下，如今暫存區是乾淨的，工做區有修改：

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt

還記得如何丟棄工做區的修改嗎？

$ git checkout -- readme.txt $ git status On branch master nothing to commit, working tree clean

整個世界終於清靜了！

如今，假設你不但改錯了東西，還從暫存區提交到了版本庫，怎麼辦呢？還記得版本回退一節嗎？能夠回退到上一個版本。不過，這是有條件的，就是你尚未把本身的本地版本庫推送到遠程。還記得Git是分佈式版本控制系統嗎？咱們後面會講到遠程版本庫，一旦你把stupid boss提交推送到遠程版本庫，你就真的慘了……

小結

又到了小結時間。

場景1：當你改亂了工做區某個文件的內容，想直接丟棄工做區的修改時，用命令git checkout -- file。

場景2：當你不但改亂了工做區某個文件的內容，還添加到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset HEAD <file>，就回到了場景1，第二步按場景1操做。

場景3：已經提交了不合適的修改到版本庫時，想要撤銷本次提交，參考版本回退一節，不過前提是沒有推送到遠程庫。

4.5 刪除文件

在Git中，刪除也是一個修改操做，咱們實戰一下，先添加一個新文件test.txt到Git而且提交：

$ git add test.txt

$ git commit -m "add test.txt" [master b84166e] add test.txt 1 file changed, 1 insertion(+) create mode 100644 test.txt

通常狀況下，你一般直接在文件管理器中把沒用的文件刪了，或者用rm命令刪了：

$ rm test.txt

這個時候，Git知道你刪除了文件，所以，工做區和版本庫就不一致了，git status命令會馬上告訴你哪些文件被刪除了：

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: test.txt no changes added to commit (use "git add" and/or "git commit -a")

如今你有兩個選擇，一是確實要從版本庫中刪除該文件，那就用命令git rm刪掉，而且git commit：

$ git rm test.txt
rm 'test.txt'

$ git commit -m "remove test.txt" [master d46f35e] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt

如今，文件就從版本庫中被刪除了。

小提示：先手動刪除文件，而後使用git rm <file>和git add<file>效果是同樣的。

另外一種狀況是刪錯了，由於版本庫裏還有呢，因此能夠很輕鬆地把誤刪的文件恢復到最新版本：

$ git checkout -- test.txt

git checkout實際上是用版本庫裏的版本替換工做區的版本，不管工做區是修改仍是刪除，均可以「一鍵還原」。

注意：歷來沒有被添加到版本庫就被刪除的文件，是沒法恢復的！

小結

命令git rm用於刪除一個文件。若是一個文件已經被提交到版本庫，那麼你永遠不用擔憂誤刪，可是要當心，你只能恢復文件到最新版本，你會丟失最近一次提交後你修改的內容。

5 遠程倉庫

到目前爲止，咱們已經掌握瞭如何在Git倉庫裏對一個文件進行時光穿梭，你不再用擔憂文件備份或者丟失的問題了。

但是有用過集中式版本控制系統SVN的童鞋會站出來講，這些功能在SVN裏早就有了，沒看出Git有什麼特別的地方。

沒錯，若是隻是在一個倉庫裏管理文件歷史，Git和SVN真沒啥區別。爲了保證你如今所學的Git物超所值，未來絕對不會後悔，同時爲了打擊已經不幸學了SVN的童鞋，本章開始介紹Git的殺手級功能之一（注意是之一，也就是後面還有之二，之三……）：遠程倉庫。

Git是分佈式版本控制系統，同一個Git倉庫，能夠分佈到不一樣的機器上。怎麼分佈呢？最先，確定只有一臺機器有一個原始版本庫，此後，別的機器能夠「克隆」這個原始版本庫，並且每臺機器的版本庫其實都是同樣的，並無主次之分。

你確定會想，至少須要兩臺機器才能玩遠程庫不是？可是我只有一臺電腦，怎麼玩？

其實一臺電腦上也是能夠克隆多個版本庫的，只要不在同一個目錄下。不過，現實生活中是不會有人這麼傻的在一臺電腦上搞幾個遠程庫玩，由於一臺電腦上搞幾個遠程庫徹底沒有意義，並且硬盤掛了會致使全部庫都掛掉，因此我也不告訴你在一臺電腦上怎麼克隆多個倉庫。

實際狀況每每是這樣，找一臺電腦充當服務器的角色，天天24小時開機，其餘每一個人都從這個「服務器」倉庫克隆一份到本身的電腦上，而且各自把各自的提交推送到服務器倉庫裏，也從服務器倉庫中拉取別人的提交。

徹底能夠本身搭建一臺運行Git的服務器，不過現階段，爲了學Git先搭個服務器絕對是小題大做。好在這個世界上有個叫GitHub的神奇的網站，從名字就能夠看出，這個網站就是提供Git倉庫託管服務的，因此，只要註冊一個GitHub帳號，就能夠免費得到Git遠程倉庫。

在繼續閱讀後續內容前，請自行註冊GitHub帳號。因爲你的本地Git倉庫和GitHub倉庫之間的傳輸是經過SSH加密的，因此，須要一點設置：

第1步：建立SSH Key。在用戶主目錄下，看看有沒有.ssh目錄，若是有，再看看這個目錄下有沒有id_rsa和id_rsa.pub這兩個文件，若是已經有了，可直接跳到下一步。若是沒有，打開Shell（Windows下打開Git Bash），建立SSH Key：

$ ssh-keygen -t rsa -C "youremail@example.com"

你須要把郵件地址換成你本身的郵件地址，而後一路回車，使用默認值便可，因爲這個Key也不是用於軍事目的，因此也無需設置密碼。

若是一切順利的話，能夠在用戶主目錄裏找到.ssh目錄，裏面有id_rsa和id_rsa.pub兩個文件，這兩個就是SSH Key的祕鑰對，id_rsa是私鑰，不能泄露出去，id_rsa.pub是公鑰，能夠放心地告訴任何人。

第2步：登錄GitHub，打開「Account settings」，「SSH Keys」頁面：

而後，點「Add SSH Key」，填上任意Title，在Key文本框裏粘貼id_rsa.pub文件的內容：

點「Add Key」，你就應該看到已經添加的Key：

爲何GitHub須要SSH Key呢？由於GitHub須要識別出你推送的提交確實是你推送的，而不是別人冒充的，而Git支持SSH協議，因此，GitHub只要知道了你的公鑰，就能夠確認只有你本身才能推送。

固然，GitHub容許你添加多個Key。假定你有若干電腦，你一下子在公司提交，一下子在家裏提交，只要把每臺電腦的Key都添加到GitHub，就能夠在每臺電腦上往GitHub推送了。

最後友情提示，在GitHub上免費託管的Git倉庫，任何人均可以看到喔（但只有你本身才能改）。因此，不要把敏感信息放進去。

若是你不想讓別人看到Git庫，有兩個辦法，一個是交點保護費，讓GitHub把公開的倉庫變成私有的，這樣別人就看不見了（不可讀更不可寫）。另外一個辦法是本身動手，搭一個Git服務器，由於是你本身的Git服務器，因此別人也是看不見的。這個方法咱們後面會講到的，至關簡單，公司內部開發必備。

確保你擁有一個GitHub帳號後，咱們就即將開始遠程倉庫的學習。

小結

「有了遠程倉庫，媽媽不再用擔憂個人硬盤了。」——Git點讀機

5.1 添加遠程庫

閱讀: 5524751

如今的情景是，你已經在本地建立了一個Git倉庫後，又想在GitHub建立一個Git倉庫，而且讓這兩個倉庫進行遠程同步，這樣，GitHub上的倉庫既能夠做爲備份，又可讓其餘人經過該倉庫來協做，真是一舉多得。

首先，登錄GitHub，而後，在右上角找到「Create a new repo」按鈕，建立一個新的倉庫：

在Repository name填入learngit，其餘保持默認設置，點擊「Create repository」按鈕，就成功地建立了一個新的Git倉庫：

目前，在GitHub上的這個learngit倉庫仍是空的，GitHub告訴咱們，能夠從這個倉庫克隆出新的倉庫，也能夠把一個已有的本地倉庫與之關聯，而後，把本地倉庫的內容推送到GitHub倉庫。

如今，咱們根據GitHub的提示，在本地的learngit倉庫下運行命令：

$ git remote add origin git@github.com:michaelliao/learngit.git

請千萬注意，把上面的michaelliao替換成你本身的GitHub帳戶名，不然，你在本地關聯的就是個人遠程庫，關聯沒有問題，可是你之後推送是推不上去的，由於你的SSH Key公鑰不在個人帳戶列表中。

添加後，遠程庫的名字就是origin，這是Git默認的叫法，也能夠改爲別的，可是origin這個名字一看就知道是遠程庫。

下一步，就能夠把本地庫的全部內容推送到遠程庫上：

$ git push -u origin master
Counting objects: 20, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (20/20), 1.64 KiB | 560.00 KiB/s, done.
Total 20 (delta 5), reused 0 (delta 0)
remote: Resolving deltas: 100% (5/5), done.
To github.com:michaelliao/learngit.git
 * [new branch]      master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.

把本地庫的內容推送到遠程，用git push命令，其實是把當前分支master推送到遠程。

因爲遠程庫是空的，咱們第一次推送master分支時，加上了-u參數，Git不但會把本地的master分支內容推送的遠程新的master分支，還會把本地的master分支和遠程的master分支關聯起來，在之後的推送或者拉取時就能夠簡化命令。

推送成功後，能夠馬上在GitHub頁面中看到遠程庫的內容已經和本地如出一轍：

從如今起，只要本地做了提交，就能夠經過命令：

$ git push origin master

把本地master分支的最新修改推送至GitHub，如今，你就擁有了真正的分佈式版本庫！

SSH警告

當你第一次使用Git的clone或者push命令鏈接GitHub時，會獲得一個警告：

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

這是由於Git使用SSH鏈接，而SSH鏈接在第一次驗證GitHub服務器的Key時，須要你確認GitHub的Key的指紋信息是否真的來自GitHub的服務器，輸入yes回車便可。

Git會輸出一個警告，告訴你已經把GitHub的Key添加到本機的一個信任列表裏了：

Warning: Permanently added 'github.com' (RSA) to the list of known hosts.

這個警告只會出現一次，後面的操做就不會有任何警告了。

若是你實在擔憂有人冒充GitHub服務器，輸入yes前能夠對照GitHub的RSA Key的指紋信息是否與SSH鏈接給出的一致。

小結

要關聯一個遠程庫，使用命令git remote add origin git@server-name:path/repo-name.git；

關聯後，使用命令git push -u origin master第一次推送master分支的全部內容；

此後，每次本地提交後，只要有必要，就能夠使用命令git push origin master推送最新修改；

分佈式版本系統的最大好處之一是在本地工做徹底不須要考慮遠程庫的存在，也就是有沒有聯網均可以正常工做，而SVN在沒有聯網的時候是拒絕幹活的！當有網絡的時候，再把本地提交推送一下就完成了同步，真是太方便了！

5.2 從遠程庫克隆

上次咱們講了先有本地庫，後有遠程庫的時候，如何關聯遠程庫。

如今，假設咱們從零開發，那麼最好的方式是先建立遠程庫，而後，從遠程庫克隆。

首先，登錄GitHub，建立一個新的倉庫，名字叫gitskills：

咱們勾選Initialize this repository with a README，這樣GitHub會自動爲咱們建立一個README.md文件。建立完畢後，能夠看到README.md文件：

如今，遠程庫已經準備好了，下一步是用命令git clone克隆一個本地庫：

$ git clone git@github.com:michaelliao/gitskills.git Cloning into 'gitskills'... remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3 Receiving objects: 100% (3/3), done.

注意把Git庫的地址換成你本身的，而後進入gitskills目錄看看，已經有README.md文件了：

$ cd gitskills $ ls README.md

若是有多我的協做開發，那麼每一個人各自從遠程克隆一份就能夠了。

你也許還注意到，GitHub給出的地址不止一個，還能夠用https://github.com/michaelliao/gitskills.git這樣的地址。實際上，Git支持多種協議，默認的git://使用ssh，但也能夠使用https等其餘協議。

使用https除了速度慢之外，還有個最大的麻煩是每次推送都必須輸入口令，可是在某些只開放http端口的公司內部就沒法使用ssh協議而只能用https。

小結

要克隆一個倉庫，首先必須知道倉庫的地址，而後使用git clone命令克隆。

Git支持多種協議，包括https，但經過ssh支持的原生git協議速度最快。

6 分支管理

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

若是兩個平行宇宙互不干擾，那對如今的你也沒啥影響。不過，在某個時間點，兩個平行宇宙合併了，結果，你既學會了Git又學會了SVN！

分支在實際中有什麼用呢？假設你準備開發一個新功能，可是須要兩週才能完成，第一週你寫了50%的代碼，若是馬上提交，因爲代碼還沒寫完，不完整的代碼庫會致使別人不能幹活了。若是等代碼所有寫完再一次提交，又存在丟失天天進度的巨大風險。

如今有了分支，就不用怕了。你建立了一個屬於你本身的分支，別人看不到，還繼續在原來的分支上正常工做，而你在本身的分支上幹活，想提交就提交，直到開發完畢後，再一次性合併到原來的分支上，這樣，既安全，又不影響別人工做。

其餘版本控制系統如SVN等都有分支管理，可是用過以後你會發現，這些版本控制系統建立和切換分支比蝸牛還慢，簡直讓人沒法忍受，結果分支功能成了擺設，你們都不去用。

但Git的分支是不同凡響的，不管建立、切換和刪除分支，Git在1秒鐘以內就能完成！不管你的版本庫是1個文件仍是1萬個文件。

6.1 建立與合併分支

在版本回退裏，你已經知道，每次提交，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，只有一條時間線，在Git裏，這個分支叫主分支，即master分支。HEAD嚴格來講不是指向提交，而是指向master，master纔是指向提交的，因此，HEAD指向的就是當前分支。

一開始的時候，master分支是一條線，Git用master指向最新的提交，再用HEAD指向master，就能肯定當前分支，以及當前分支的提交點：

每次提交，master分支都會向前移動一步，這樣，隨着你不斷提交，master分支的線也愈來愈長：

video: http://liaoxuefeng.gitee.io/git-resources/master-branch-forward.mp4

當咱們建立新的分支，例如dev時，Git新建了一個指針叫dev，指向master相同的提交，再把HEAD指向dev，就表示當前分支在dev上：

你看，Git建立一個分支很快，由於除了增長一個dev指針，改改HEAD的指向，工做區的文件都沒有任何變化！

不過，從如今開始，對工做區的修改和提交就是針對dev分支了，好比新提交一次後，dev指針往前移動一步，而master指針不變：

假如咱們在dev上的工做完成了，就能夠把dev合併到master上。Git怎麼合併呢？最簡單的方法，就是直接把master指向dev的當前提交，就完成了合併：

因此Git合併分支也很快！就改改指針，工做區內容也不變！

合併完分支後，甚至能夠刪除dev分支。刪除dev分支就是把dev指針給刪掉，刪掉後，咱們就剩下了一條master分支：

真是太神奇了，你看得出來有些提交是經過分支完成的嗎？

video: http://liaoxuefeng.gitee.io/git-resources/master-and-dev-ff.mp4

下面開始實戰。

首先，咱們建立dev分支，而後切換到dev分支：

$ git checkout -b dev Switched to a new branch 'dev'

git checkout命令加上-b參數表示建立並切換，至關於如下兩條命令：

$ git branch dev $ git checkout dev Switched to branch 'dev'

而後，用git branch命令查看當前分支：

$ git branch * dev master

git branch命令會列出全部分支，當前分支前面會標一個*號。

而後，咱們就能夠在dev分支上正常提交，好比對readme.txt作個修改，加上一行：

Creating a new branch is quick.

而後提交：

$ git add readme.txt $ git commit -m "branch test" [dev b17d20e] branch test 1 file changed, 1 insertion(+)

如今，dev分支的工做完成，咱們就能夠切換回master分支：

$ git checkout master Switched to branch 'master'

切換回master分支後，再查看一個readme.txt文件，剛纔添加的內容不見了！由於那個提交是在dev分支上，而master分支此刻的提交點並無變：

如今，咱們把dev分支的工做成果合併到master分支上：

$ git merge dev Updating d46f35e..b17d20e Fast-forward readme.txt | 1 + 1 file changed, 1 insertion(+)

git merge命令用於合併指定分支到當前分支。合併後，再查看readme.txt的內容，就能夠看到，和dev分支的最新提交是徹底同樣的。

注意到上面的Fast-forward信息，Git告訴咱們，此次合併是「快進模式」，也就是直接把master指向dev的當前提交，因此合併速度很是快。

固然，也不是每次合併都能Fast-forward，咱們後面會講其餘方式的合併。

合併完成後，就能夠放心地刪除dev分支了：

$ git branch -d dev Deleted branch dev (was b17d20e).

刪除後，查看branch，就只剩下master分支了：

$ git branch * master

由於建立、合併和刪除分支很是快，因此Git鼓勵你使用分支完成某個任務，合併後再刪掉分支，這和直接在master分支上工做效果是同樣的，但過程更安全。

小結

Git鼓勵大量使用分支：

查看分支：git branch

建立分支：git branch <name>

切換分支：git checkout <name>

建立+切換分支：git checkout -b <name>

合併某分支到當前分支：git merge <name>

刪除分支：git branch -d <name>

6.2 解決衝突

人生不如意之事十之八九，合併分支每每也不是一路順風的。

準備新的feature1分支，繼續咱們的新分支開發：

$ 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 14096d0] 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. (use "git push" to publish your local commits)

Git還會自動提示咱們當前master分支比遠程的master分支要超前1個提交。

在master分支上把readme.txt文件的最後一行改成：

Creating a new branch is quick & simple.

提交：

$ git add readme.txt $ git commit -m "& simple" [master 5dc6824] & simple 1 file changed, 1 insertion(+), 1 deletion(-)

如今，master分支和feature1分支各自都分別有新的提交，變成了這樣：

這種狀況下，Git沒法執行「快速合併」，只能試圖把各自的修改合併起來，但這種合併就可能會有衝突，咱們試試看：

$ 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文件存在衝突，必須手動解決衝突後再提交。git status也能夠告訴咱們衝突的文件：

$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits. (use "git push" to publish your local commits) You have unmerged paths. (fix conflicts and run "git commit") (use "git merge --abort" to abort the merge) Unmerged paths: (use "git add <file>..." to mark resolution) both modified: readme.txt no changes added to commit (use "git add" and/or "git commit -a")

咱們能夠直接查看readme.txt的內容：

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用<<<<<<<，=======，>>>>>>>標記出不一樣分支的內容，咱們修改以下後保存：

Creating a new branch is quick and simple.

再提交：

$ git add readme.txt $ git commit -m "conflict fixed" [master cf810e4] conflict fixed

如今，master分支和feature1分支變成了下圖所示：

用帶參數的git log也能夠看到分支的合併狀況：

$ git log --graph --pretty=oneline --abbrev-commit
*   cf810e4 (HEAD -> master) conflict fixed
|\  
| * 14096d0 (feature1) AND simple * | 5dc6824 & simple |/ * b17d20e branch test * d46f35e (origin/master) remove test.txt * b84166e add test.txt * 519219b git tracks changes * e43a48b understand how stage works * 1094adb append GPL * e475afc add distributed * eaadf4e wrote a readme file

最後，刪除feature1分支：

$ git branch -d feature1 Deleted branch feature1 (was 14096d0).

工做完成。

小結

當Git沒法自動合併分支時，就必須首先解決衝突。解決衝突後，再提交，合併完成。

解決衝突就是把Git合併失敗的文件手動編輯爲咱們但願的內容，再提交。

用git log --graph命令能夠看到分支合併圖。

6.3 分支管理策略

一般，合併分支時，若是可能，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支信息。

若是要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就能夠看出分支信息。

下面咱們實戰一下--no-ff方式的git merge：

首先，仍然建立並切換dev分支：

$ git checkout -b dev Switched to a new branch 'dev'

修改readme.txt文件，並提交一個新的commit：

$ git add readme.txt 
$ git commit -m "add merge" [dev f52c633] add merge 1 file changed, 1 insertion(+)

如今，咱們切換回master：

$ git checkout master Switched to branch 'master'

準備合併dev分支，請注意--no-ff參數，表示禁用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(+)

由於本次合併要建立一個新的commit，因此加上-m參數，把commit描述寫進去。

合併後，咱們用git log看看分支歷史：

$ git log --graph --pretty=oneline --abbrev-commit * e1e9c68 (HEAD -> master) merge with no-ff |\ | * f52c633 (dev) add merge |/ * cf810e4 conflict fixed ...

能夠看到，不使用Fast forward模式，merge後就像這樣：

分支策略

在實際開發中，咱們應該按照幾個基本原則進行分支管理：

首先，master分支應該是很是穩定的，也就是僅用來發布新版本，平時不能在上面幹活；

那在哪幹活呢？幹活都在dev分支上，也就是說，dev分支是不穩定的，到某個時候，好比1.0版本發佈時，再把dev分支合併到master上，在master分支發佈1.0版本；

你和你的小夥伴們每一個人都在dev分支上幹活，每一個人都有本身的分支，時不時地往dev分支上合併就能夠了。

因此，團隊合做的分支看起來就像這樣：

小結

Git分支十分強大，在團隊開發中應該充分應用。

合併分支時，加上--no-ff參數就能夠用普通模式合併，合併後的歷史有分支，能看出來曾經作過合併，而fast forward合併就看不出來曾經作過合併。

6.4 Bug分支

軟件開發中，bug就像屢見不鮮同樣。有了bug就須要修復，在Git中，因爲分支是如此的強大，因此，每一個bug均可以經過一個新的臨時分支來修復，修復後，合併分支，而後將臨時分支刪除。

當你接到一個修復一個代號101的bug的任務時，很天然地，你想建立一個分支issue-101來修復它，可是，等等，當前正在dev上進行的工做尚未提交：

$ git status
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage) new file: hello.py Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt

並非你不想提交，而是工做只進行到一半，還無法提交，預計完成還需1天時間。可是，必須在兩個小時內修復該bug，怎麼辦？

幸虧，Git還提供了一個stash功能，能夠把當前工做現場「儲藏」起來，等之後恢復現場後繼續工做：

$ git stash Saved working directory and index state WIP on dev: f52c633 add merge

如今，用git status查看工做區，就是乾淨的（除非有沒有被Git管理的文件），所以能夠放心地建立分支來修復bug。

首先肯定要在哪一個分支上修復bug，假定須要在master分支上修復，就從master建立臨時分支：

$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits) $ git checkout -b issue-101 Switched to a new branch 'issue-101'

如今修復bug，須要把「Git is free software ...」改成「Git is a free software ...」，而後提交：

$ git add readme.txt $ git commit -m "fix bug 101" [issue-101 4c805e2] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)

修復完成後，切換到master分支，並完成合並，最後刪除issue-101分支：

$ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 6 commits. (use "git push" to publish your local commits) $ git merge --no-ff -m "merged bug fix 101" issue-101 Merge made by the 'recursive' strategy. readme.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

太棒了，原計劃兩個小時的bug修復只花了5分鐘！如今，是時候接着回到dev分支幹活了！

$ git checkout dev Switched to branch 'dev' $ git status On branch dev nothing to commit, working tree clean

工做區是乾淨的，剛纔的工做現場存到哪去了？用git stash list命令看看：

$ git stash list stash@{0}: WIP on dev: f52c633 add merge

工做現場還在，Git把stash內容存在某個地方了，可是須要恢復一下，有兩個辦法：

一是用git stash apply恢復，可是恢復後，stash內容並不刪除，你須要用git stash drop來刪除；

另外一種方式是用git stash pop，恢復的同時把stash內容也刪了：

$ git stash pop
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage) new file: hello.py Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: readme.txt Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

再用git stash list查看，就看不到任何stash內容了：

$ git stash list

你能夠屢次stash，恢復的時候，先用git stash list查看，而後恢復指定的stash，用命令：

$ git stash apply stash@{0}

小結

修復bug時，咱們會經過建立新的bug分支進行修復，而後合併，最後刪除；

當手頭工做沒有完成時，先把工做現場git stash一下，而後去修復bug，修復後，再git stash pop，回到工做現場。

6.5 Feature分支

軟件開發中，總有無窮無盡的新的功能要不斷添加進來。

添加一個新功能時，你確定不但願由於一些實驗性質的代碼，把主分支搞亂了，因此，每添加一個新功能，最好新建一個feature分支，在上面開發，完成後，合併，最後，刪除該feature分支。

如今，你終於接到了一個新任務：開發代號爲Vulcan的新功能，該功能計劃用於下一代星際飛船。

因而準備開發：

$ git checkout -b feature-vulcan Switched to a new branch 'feature-vulcan'

5分鐘後，開發完畢：

$ git add vulcan.py $ git status On branch feature-vulcan Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: vulcan.py $ git commit -m "add feature vulcan" [feature-vulcan 287773e] add feature vulcan 1 file changed, 2 insertions(+) create mode 100644 vulcan.py

切回dev，準備合併：

$ git checkout dev

一切順利的話，feature分支和bug分支是相似的，合併，而後刪除。

可是！

就在此時，接到上級命令，因經費不足，新功能必須取消！

雖然白乾了，可是這個包含機密資料的分支仍是必須就地銷燬：

$ 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分支尚未被合併，若是刪除，將丟失掉修改，若是要強行刪除，須要使用大寫的-D參數。。

如今咱們強行刪除：

$ git branch -D feature-vulcan Deleted branch feature-vulcan (was 287773e).

終於刪除成功！

小結

開發一個新feature，最好新建一個分支；

若是要丟棄一個沒有被合併過的分支，能夠經過git branch -D <name>強行刪除。

6.6 多人協做

當你從遠程倉庫克隆時，實際上Git自動把本地的master分支和遠程的master分支對應起來了，而且，遠程倉庫的默認名稱是origin。

要查看遠程庫的信息，用git remote：

$ git remote origin

或者，用git remote -v顯示更詳細的信息：

$ git remote -v origin git@github.com:michaelliao/learngit.git (fetch) origin git@github.com:michaelliao/learngit.git (push)

上面顯示了能夠抓取和推送的origin的地址。若是沒有推送權限，就看不到push的地址。

推送分支

推送分支，就是把該分支上的全部本地提交推送到遠程庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠程庫對應的遠程分支上：

$ git push origin master

若是要推送其餘分支，好比dev，就改爲：

$ git push origin dev

可是，並非必定要把本地分支往遠程推送，那麼，哪些分支須要推送，哪些不須要呢？

master分支是主分支，所以要時刻與遠程同步；
dev分支是開發分支，團隊全部成員都須要在上面工做，因此也須要與遠程同步；
bug分支只用於在本地修復bug，就不必推到遠程了，除非老闆要看看你每週到底修復了幾個bug；
feature分支是否推到遠程，取決於你是否和你的小夥伴合做在上面開發。

總之，就是在Git中，分支徹底能夠在本地本身藏着玩，是否推送，視你的心情而定！

抓取分支

多人協做時，你們都會往master和dev分支上推送各自的修改。

如今，模擬一個你的小夥伴，能夠在另外一臺電腦（注意要把SSH Key添加到GitHub）或者同一臺電腦的另外一個目錄下克隆：

$ git clone git@github.com:michaelliao/learngit.git Cloning into 'learngit'... remote: Counting objects: 40, done. remote: Compressing objects: 100% (21/21), done. remote: Total 40 (delta 14), reused 40 (delta 14), pack-reused 0 Receiving objects: 100% (40/40), done. Resolving deltas: 100% (14/14), done.

當你的小夥伴從遠程庫clone時，默認狀況下，你的小夥伴只能看到本地的master分支。不信能夠用git branch命令看看：

$ git branch * master

如今，你的小夥伴要在dev分支上開發，就必須建立遠程origin的dev分支到本地，因而他用這個命令建立本地dev分支：

$ git checkout -b dev origin/dev

如今，他就能夠在dev上繼續修改，而後，時不時地把dev分支push到遠程：

$ git add env.txt

$ git commit -m "add env" [dev 7a5e5dd] add env 1 file changed, 1 insertion(+) create mode 100644 env.txt $ git push origin dev Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 308 bytes | 308.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git f52c633..7a5e5dd dev -> dev

你的小夥伴已經向origin/dev分支推送了他的提交，而碰巧你也對一樣的文件做了修改，並試圖推送：

$ cat env.txt
env

$ git add env.txt

$ git commit -m "add new env" [dev 7bd91f1] add new env 1 file changed, 1 insertion(+) create mode 100644 env.txt $ git push origin dev To github.com:michaelliao/learngit.git ! [rejected] dev -> dev (non-fast-forward) error: failed to push some refs to 'git@github.com:michaelliao/learngit.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

推送失敗，由於你的小夥伴的最新提交和你試圖推送的提交有衝突，解決辦法也很簡單，Git已經提示咱們，先用git pull把最新的提交從origin/dev抓下來，而後，在本地合併，解決衝突，再推送：

$ git pull
There is no tracking information for the current branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull <remote> <branch> If you wish to set tracking information for this branch you can do so with: git branch --set-upstream-to=origin/<branch> dev

git pull也失敗了，緣由是沒有指定本地dev分支與遠程origin/dev分支的連接，根據提示，設置dev和origin/dev的連接：

$ git branch --set-upstream-to=origin/dev dev Branch 'dev' set up to track remote branch 'dev' from 'origin'.

再pull：

$ git pull Auto-merging env.txt CONFLICT (add/add): Merge conflict in env.txt Automatic merge failed; fix conflicts and then commit the result.

這回git pull成功，可是合併有衝突，須要手動解決，解決的方法和分支管理中的解決衝突徹底同樣。解決後，提交，再push：

$ git commit -m "fix env conflict" [dev 57c53ab] fix env conflict $ git push origin dev Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 621 bytes | 621.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git 7a5e5dd..57c53ab dev -> dev

所以，多人協做的工做模式一般是這樣：

首先，能夠試圖用git push origin <branch-name>推送本身的修改；
若是推送失敗，則由於遠程分支比你的本地更新，須要先用git pull試圖合併；
若是合併有衝突，則解決衝突，並在本地提交；
沒有衝突或者解決掉衝突後，再用git push origin <branch-name>推送就能成功！

若是git pull提示no tracking information，則說明本地分支和遠程分支的連接關係沒有建立，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

這就是多人協做的工做模式，一旦熟悉了，就很是簡單。

小結

查看遠程庫信息，使用git remote -v；
本地新建的分支若是不推送到遠程，對其餘人就是不可見的；
從本地推送分支，使用git push origin branch-name，若是推送失敗，先用git pull抓取遠程的新提交；
在本地建立和遠程分支對應的分支，使用git checkout -b branch-name origin/branch-name，本地和遠程分支的名稱最好一致；
創建本地分支和遠程分支的關聯，使用git branch --set-upstream branch-name origin/branch-name；
從遠程抓取分支，使用git pull，若是有衝突，要先處理衝突。

6.7 Rebase

在上一節咱們看到了，多人在同一個分支上協做時，很容易出現衝突。即便沒有衝突，後push的童鞋不得不先pull，在本地合併，而後才能push成功。

每次合併再push後，分支變成了這樣：

$ git log --graph --pretty=oneline --abbrev-commit
* d1be385 (HEAD -> master, origin/master) init hello
*   e5e69f1 Merge branch 'dev' |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env | |/ * | 12a631b merged bug fix 101 |\ \ | * | 4c805e2 fix bug 101 |/ / * | e1e9c68 merge with no-ff |\ \ | |/ | * f52c633 add merge |/ * cf810e4 conflict fixed

總之看上去很亂，有強迫症的童鞋會問：爲何Git的提交歷史不能是一條幹淨的直線？

實際上是能夠作到的！

Git有一種稱爲rebase的操做，有人把它翻譯成「變基」。

先不要隨意展開想象。咱們仍是從實際問題出發，看看怎麼把分叉的提交變成直線。

在和遠程分支同步後，咱們對hello.py這個文件作了兩次提交。用git log命令看看：

$ git log --graph --pretty=oneline --abbrev-commit * 582d922 (HEAD -> master) add author * 8875536 add comment * d1be385 (origin/master) init hello * e5e69f1 Merge branch 'dev' |\ | * 57c53ab (origin/dev, dev) fix env conflict | |\ | | * 7a5e5dd add env | * | 7bd91f1 add new env ...

注意到Git用(HEAD -> master)和(origin/master)標識出當前分支的HEAD和遠程origin的位置分別是582d922 add author和d1be385 init hello，本地分支比遠程分支快兩個提交。

如今咱們嘗試推送本地分支：

$ git push origin master
To github.com:michaelliao/learngit.git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to 'git@github.com:michaelliao/learngit.git'
hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.

很不幸，失敗了，這說明有人先於咱們推送了遠程分支。按照經驗，先pull一下：

$ git pull remote: Counting objects: 3, done. remote: Compressing objects: 100% (1/1), done. remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0 Unpacking objects: 100% (3/3), done. From github.com:michaelliao/learngit d1be385..f005ed4 master -> origin/master * [new tag] v1.0 -> v1.0 Auto-merging hello.py Merge made by the 'recursive' strategy. hello.py | 1 + 1 file changed, 1 insertion(+)

再用git status看看狀態：

$ git status
On branch master
Your branch is ahead of 'origin/master' by 3 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

加上剛纔合併的提交，如今咱們本地分支比遠程分支超前3個提交。

用git log看看：

$ git log --graph --pretty=oneline --abbrev-commit * e0ea545 (HEAD -> master) Merge branch 'master' of github.com:michaelliao/learngit |\ | * f005ed4 (origin/master) set exit=1 * | 582d922 add author * | 8875536 add comment |/ * d1be385 init hello ...

對強迫症童鞋來講，如今事情有點不對頭，提交歷史分叉了。若是如今把本地分支push到遠程，有沒有問題？

有！

什麼問題？

很差看！

有沒有解決方法？

有！

這個時候，rebase就派上了用場。咱們輸入命令git rebase試試：

$ git rebase First, rewinding head to replay your work on top of it... Applying: add comment Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py Applying: add author Using index info to reconstruct a base tree... M hello.py Falling back to patching base and 3-way merge... Auto-merging hello.py

輸出了一大堆操做，究竟是啥效果？再用git log看看：

$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master) add author * 3611cfe add comment * f005ed4 (origin/master) set exit=1 * d1be385 init hello ...

本來分叉的提交如今變成一條直線了！這種神奇的操做是怎麼實現的？其實原理很是簡單。咱們注意觀察，發現Git把咱們本地的提交「挪動」了位置，放到了f005ed4 (origin/master) set exit=1以後，這樣，整個提交歷史就成了一條直線。rebase操做先後，最終的提交內容是一致的，可是，咱們本地的commit修改內容已經變化了，它們的修改再也不基於d1be385 init hello，而是基於f005ed4 (origin/master) set exit=1，但最後的提交7e61ed4內容是一致的。

這就是rebase操做的特色：把分叉的提交歷史「整理」成一條直線，看上去更直觀。缺點是本地的分叉提交已經被修改過了。

最後，經過push操做把本地分支推送到遠程：

Mac:~/learngit michael$ git push origin master Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 576 bytes | 576.00 KiB/s, done. Total 6 (delta 2), reused 0 (delta 0) remote: Resolving deltas: 100% (2/2), completed with 1 local object. To github.com:michaelliao/learngit.git f005ed4..7e61ed4 master -> master

再用git log看看效果：

$ git log --graph --pretty=oneline --abbrev-commit * 7e61ed4 (HEAD -> master, origin/master) add author * 3611cfe add comment * f005ed4 set exit=1 * d1be385 init hello ...

遠程分支的提交歷史也是一條直線。

小結

rebase操做能夠把本地未push的分叉提交歷史整理成直線；
rebase的目的是使得咱們在查看歷史提交的變化時更容易，由於分叉的提交須要三方對比。

7 標籤管理

發佈一個版本時，咱們一般先在版本庫中打一個標籤（tag），這樣，就惟一肯定了打標籤時刻的版本。未來不管何時，取某個標籤的版本，就是把那個打標籤的時刻的歷史版本取出來。因此，標籤也是版本庫的一個快照。

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

Git有commit，爲何還要引入tag？

「請把上週一的那個版本打包發佈，commit號是6a5819e...」

「一串亂七八糟的數字很差找！」

若是換一個辦法：

「請把上週一的那個版本打包發佈，版本號是v1.2」

「好的，按照tag v1.2查找commit就行！」

因此，tag就是一個讓人容易記住的有意義的名字，它跟某個commit綁在一塊兒。

7.1 建立標籤

在Git中打標籤很是簡單，首先，切換到須要打標籤的分支上：

$ git branch * dev master $ git checkout master Switched to branch 'master'

而後，敲命令git tag <name>就能夠打一個新標籤：

$ git tag v1.0

能夠用命令git tag查看全部標籤：

$ git tag v1.0

默認標籤是打在最新提交的commit上的。有時候，若是忘了打標籤，好比，如今已是週五了，但應該在週一打的標籤沒有打，怎麼辦？

方法是找到歷史提交的commit id，而後打上就能夠了：

$ git log --pretty=oneline --abbrev-commit 12a631b (HEAD -> master, tag: v1.0, origin/master) merged bug fix 101 4c805e2 fix bug 101 e1e9c68 merge with no-ff f52c633 add merge cf810e4 conflict fixed 5dc6824 & simple 14096d0 AND simple b17d20e branch test d46f35e remove test.txt b84166e add test.txt 519219b git tracks changes e43a48b understand how stage works 1094adb append GPL e475afc add distributed eaadf4e wrote a readme file

比方說要對add merge此次提交打標籤，它對應的commit id是f52c633，敲入命令：

$ git tag v0.9 f52c633

再用命令git tag查看標籤：

$ git tag v0.9 v1.0

注意，標籤不是按時間順序列出，而是按字母排序的。能夠用git show <tagname>查看標籤信息：

$ git show v0.9 commit f52c63349bc3c1593499807e5c8e972b82c8f286 (tag: v0.9) Author: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 21:56:54 2018 +0800 add merge diff --git a/readme.txt b/readme.txt ...

能夠看到，v0.9確實打在add merge此次提交上。

還能夠建立帶有說明的標籤，用-a指定標籤名，-m指定說明文字：

$ git tag -a v0.1 -m "version 0.1 released" 1094adb

用命令git show <tagname>能夠看到說明文字：

$ git show v0.1
tag v0.1
Tagger: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 22:48:43 2018 +0800 version 0.1 released commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (tag: v0.1) Author: Michael Liao <askxuefeng@gmail.com> Date: Fri May 18 21:06:15 2018 +0800 append GPL diff --git a/readme.txt b/readme.txt ...

注意：標籤老是和某個commit掛鉤。若是這個commit既出如今master分支，又出如今dev分支，那麼在這兩個分支上均可以看到這個標籤。

小結

命令git tag <tagname>用於新建一個標籤，默認爲HEAD，也能夠指定一個commit id；
命令git tag -a <tagname> -m "blablabla..."能夠指定標籤信息；
命令git tag能夠查看全部標籤。

7.2 操做標籤

若是標籤打錯了，也能夠刪除：

$ git tag -d v0.1 Deleted tag 'v0.1' (was f15b0dd)

由於建立的標籤都只存儲在本地，不會自動推送到遠程。因此，打錯的標籤能夠在本地安全刪除。

若是要推送某個標籤到遠程，使用命令git push origin <tagname>：

$ git push origin v1.0 Total 0 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git * [new tag] v1.0 -> v1.0

或者，一次性推送所有還沒有推送到遠程的本地標籤：

$ git push origin --tags Total 0 (delta 0), reused 0 (delta 0) To github.com:michaelliao/learngit.git * [new tag] v0.9 -> v0.9

若是標籤已經推送到遠程，要刪除遠程標籤就麻煩一點，先從本地刪除：

$ git tag -d v0.9 Deleted tag 'v0.9' (was f52c633)

而後，從遠程刪除。刪除命令也是push，可是格式以下：

$ git push origin :refs/tags/v0.9 To github.com:michaelliao/learngit.git - [deleted] v0.9

要看看是否真的從遠程庫刪除了標籤，能夠登錄GitHub查看。

小結

命令git push origin <tagname>能夠推送一個本地標籤；
命令git push origin --tags能夠推送所有未推送過的本地標籤；
命令git tag -d <tagname>能夠刪除一個本地標籤；
命令git push origin :refs/tags/<tagname>能夠刪除一個遠程標籤。

8 使用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 ────────────────────────────────────┐
│                                             │
│ ┌─────────────────┐     ┌─────────────────┐ │
│ │ twbs/bootstrap  │────>│  my/bootstrap   │ │
│ └─────────────────┘     └─────────────────┘ │
│                                  ▲          │
└──────────────────────────────────┼──────────┘
                                   ▼
                          ┌─────────────────┐
                          │ local/bootstrap │
                          └─────────────────┘

若是你想修復bootstrap的一個bug，或者新增一個功能，馬上就能夠開始幹活，幹完後，往本身的倉庫推送。

若是你但願bootstrap的官方庫能接受你的修改，你就能夠在GitHub上發起一個pull request。固然，對方是否接受你的pull request就不必定了。

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

小結

在GitHub上，能夠任意Fork開源倉庫；
本身擁有Fork後的倉庫的讀寫權限；
能夠推送pull request給官方倉庫來貢獻代碼。

9 使用碼雲

使用GitHub時，國內的用戶常常遇到的問題是訪問速度太慢，有時候還會出現沒法鏈接的狀況（緣由你懂的）。

若是咱們但願體驗Git飛通常的速度，能夠使用國內的Git託管服務——碼雲（gitee.com）。

和GitHub相比，碼雲也提供免費的Git倉庫。此外，還集成了代碼質量檢測、項目演示等功能。對於團隊協做開發，碼雲還提供了項目管理、代碼託管、文檔管理的服務，5人如下小團隊免費。

碼雲的免費版本也提供私有庫功能，只是有5人的成員上限。

使用碼雲和使用GitHub相似，咱們在碼雲上註冊帳號並登陸後，須要先上傳本身的SSH公鑰。選擇右上角用戶頭像 -> 菜單「修改資料」，而後選擇「SSH公鑰」，填寫一個便於識別的標題，而後把用戶主目錄下的.ssh/id_rsa.pub文件的內容粘貼進去：

點擊「肯定」便可完成並看到剛纔添加的Key：

若是咱們已經有了一個本地的git倉庫（例如，一個名爲learngit的本地庫），如何把它關聯到碼雲的遠程庫上呢？

首先，咱們在碼雲上建立一個新的項目，選擇右上角用戶頭像 -> 菜單「控制面板」，而後點擊「建立項目」：

項目名稱最好與本地庫保持一致：

而後，咱們在本地庫上使用命令git remote add把它和碼雲的遠程庫關聯：

git remote add origin git@gitee.com:liaoxuefeng/learngit.git

以後，就能夠正常地用git push和git pull推送了！

若是在使用命令git remote add時報錯：

git remote add origin git@gitee.com:liaoxuefeng/learngit.git fatal: remote origin already exists.

這說明本地庫已經關聯了一個名叫origin的遠程庫，此時，能夠先用git remote -v查看遠程庫信息：

git remote -v
origin	git@github.com:michaelliao/learngit.git (fetch) origin git@github.com:michaelliao/learngit.git (push)

能夠看到，本地庫已經關聯了origin的遠程庫，而且，該遠程庫指向GitHub。

咱們能夠刪除已有的GitHub遠程庫：

git remote rm origin

再關聯碼雲的遠程庫（注意路徑中須要填寫正確的用戶名）：

git remote add origin git@gitee.com:liaoxuefeng/learngit.git

此時，咱們再查看遠程庫信息：

git remote -v
origin	git@gitee.com:liaoxuefeng/learngit.git (fetch) origin git@gitee.com:liaoxuefeng/learngit.git (push)

如今能夠看到，origin已經被關聯到碼雲的遠程庫了。經過git push命令就能夠把本地庫推送到Gitee上。

有的小夥伴又要問了，一個本地庫能不能既關聯GitHub，又關聯碼雲呢？

答案是確定的，由於git自己是分佈式版本控制系統，能夠同步到另一個遠程庫，固然也能夠同步到另外兩個遠程庫。

使用多個遠程庫時，咱們要注意，git給遠程庫起的默認名稱是origin，若是有多個遠程庫，咱們須要用不一樣的名稱來標識不一樣的遠程庫。

仍然以learngit本地庫爲例，咱們先刪除已關聯的名爲origin的遠程庫：

git remote rm origin

而後，先關聯GitHub的遠程庫：

git remote add github git@github.com:michaelliao/learngit.git

注意，遠程庫的名稱叫github，不叫origin了。

接着，再關聯碼雲的遠程庫：

git remote add gitee git@gitee.com:liaoxuefeng/learngit.git

一樣注意，遠程庫的名稱叫gitee，不叫origin。

如今，咱們用git remote -v查看遠程庫信息，能夠看到兩個遠程庫：

git remote -v
gitee	git@gitee.com:liaoxuefeng/learngit.git (fetch) gitee git@gitee.com:liaoxuefeng/learngit.git (push) github git@github.com:michaelliao/learngit.git (fetch) github git@github.com:michaelliao/learngit.git (push)

若是要推送到GitHub，使用命令：

git push github master

若是要推送到碼雲，使用命令：

git push gitee master

這樣一來，咱們的本地庫就能夠同時與多個遠程庫互相同步：

┌─────────┐ ┌─────────┐
│ GitHub  │ │  Gitee  │
└─────────┘ └─────────┘
     ▲           ▲
     └─────┬─────┘
           │
    ┌─────────────┐
    │ Local Repo  │
    └─────────────┘

碼雲也一樣提供了Pull request功能，可讓其餘小夥伴參與到開源項目中來。你能夠經過Fork個人倉庫：https://gitee.com/liaoxuefeng/learngit，建立一個your-gitee-id.txt的文本文件，寫點本身學習Git的心得，而後推送一個pull request給我，這個倉庫會在碼雲和GitHub作雙向同步。

10 自定義Git

在安裝Git一節中，咱們已經配置了user.name和user.email，實際上，Git還有不少可配置項。

好比，讓Git顯示顏色，會讓命令輸出看起來更醒目：

$ git config --global color.ui true

這樣，Git會適當地顯示不一樣的顏色，好比git status命令：

文件名就會標上顏色。

咱們在後面還會介紹如何更好地配置Git，以便讓你的工做更高效。

10.1 忽略特殊文件

有些時候，你必須把某些文件放到Git工做目錄中，但又不能提交它們，好比保存了數據庫密碼的配置文件啦，等等，每次git status都會顯示Untracked files ...，有強迫症的童鞋內心確定不爽。

好在Git考慮到了你們的感覺，這個問題解決起來也很簡單，在Git工做區的根目錄下建立一個特殊的.gitignore文件，而後把要忽略的文件名填進去，Git就會自動忽略這些文件。

不須要從頭寫.gitignore文件，GitHub已經爲咱們準備了各類配置文件，只須要組合一下就能夠使用了。全部配置文件能夠直接在線瀏覽：https://github.com/github/gitignore

忽略文件的原則是：

忽略操做系統自動生成的文件，好比縮略圖等；
忽略編譯生成的中間文件、可執行文件等，也就是若是一個文件是經過另外一個文件自動生成的，那自動生成的文件就不必放進版本庫，好比Java編譯產生的.class文件；
忽略你本身的帶有敏感信息的配置文件，好比存放口令的配置文件。

舉個例子：

假設你在Windows下進行Python開發，Windows會自動在有圖片的目錄下生成隱藏的縮略圖文件，若是有自定義目錄，目錄下就會有Desktop.ini文件，所以你須要忽略Windows自動生成的垃圾文件：

# Windows: Thumbs.db ehthumbs.db Desktop.ini

而後，繼續忽略Python編譯產生的.pyc、.pyo、dist等文件或目錄：

# Python: *.py[cod] *.so *.egg *.egg-info dist build

加上你本身定義的文件，最終獲得一個完整的.gitignore文件，內容以下：

# 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，就完成了！固然檢驗.gitignore的標準是git status命令是否是說working directory clean。

使用Windows的童鞋注意了，若是你在資源管理器裏新建一個.gitignore文件，它會很是弱智地提示你必須輸入文件名，可是在文本編輯器裏「保存」或者「另存爲」就能夠把文件保存爲.gitignore了。

有些時候，你想添加一個文件到Git，但發現添加不了，緣由是這個文件被.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.

若是你確實想添加該文件，能夠用-f強制添加到Git：

$ git add -f App.class

或者你發現，多是.gitignore寫得有問題，須要找出來到底哪一個規則寫錯了，能夠用git check-ignore命令檢查：

$ git check-ignore -v App.class .gitignore:3:*.class App.class

Git會告訴咱們，.gitignore的第3行規則忽略了該文件，因而咱們就能夠知道應該修訂哪一個規則。

小結

忽略某些文件時，須要編寫.gitignore；
.gitignore文件自己要放到版本庫裏，而且能夠對.gitignore作版本管理！

10.2 配置別名

有沒有常常敲錯命令？好比git status？status這個單詞真心很差記。

若是敲git st就表示git status那就簡單多了，固然這種偷懶的辦法咱們是極力同意的。

咱們只須要敲一行命令，告訴Git，之後st就表示status：

$ git config --global alias.st status

好了，如今敲git st看看效果。

固然還有別的命令能夠簡寫，不少人都用co表示checkout，ci表示commit，br表示branch：

$ git config --global alias.co checkout $ git config --global alias.ci commit $ git config --global alias.br branch

之後提交就能夠簡寫成：

$ git ci -m "bala bala bala..."

--global參數是全局參數，也就是這些命令在這臺電腦的全部Git倉庫下都有用。

在撤銷修改一節中，咱們知道，命令git reset HEAD file能夠把暫存區的修改撤銷掉（unstage），從新放回工做區。既然是一個unstage操做，就能夠配置一個unstage別名：

$ git config --global alias.unstage 'reset HEAD'

當你敲入命令：

$ git unstage test.py

實際上Git執行的是：

$ git reset HEAD test.py

配置一個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"

來看看git lg的效果：

爲何不早點告訴我？別激動，咱不是爲了多記幾個英文單詞嘛！

配置文件

配置Git的時候，加上--global是針對當前用戶起做用的，若是不加，那隻針對當前的倉庫起做用。

配置文件放哪了？每一個倉庫的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]後面，要刪除別名，直接把對應的行刪掉便可。

而當前用戶的Git配置文件放在用戶主目錄下的一個隱藏文件.gitconfig中：

$ cat .gitconfig [alias] co = checkout ci = commit br = branch st = status [user] name = Your Name email = your@email.com

配置別名也能夠直接修改這個文件，若是改錯了，能夠刪掉文件從新經過命令配置。

小結

給Git配置好別名，就能夠輸入命令時偷個懶。咱們鼓勵偷懶。

10.3 搭建Git服務器

在遠程倉庫一節中，咱們講了遠程倉庫實際上和本地倉庫沒啥不一樣，純粹爲了7x24小時開機並交換你們的修改。

GitHub就是一個免費託管開源代碼的遠程倉庫。可是對於某些視源代碼如生命的商業公司來講，既不想公開源代碼，又捨不得給GitHub交保護費，那就只能本身搭建一臺Git服務器做爲私有倉庫使用。

搭建Git服務器須要準備一臺運行Linux的機器，強烈推薦用Ubuntu或Debian，這樣，經過幾條簡單的apt命令就能夠完成安裝。

假設你已經有sudo權限的用戶帳號，下面，正式開始安裝。

第一步，安裝git：

$ sudo apt-get install git

第二步，建立一個git用戶，用來運行git服務：

$ sudo adduser git

第三步，建立證書登陸：

收集全部須要登陸的用戶的公鑰，就是他們本身的id_rsa.pub文件，把全部公鑰導入到/home/git/.ssh/authorized_keys文件裏，一行一個。

第四步，初始化Git倉庫：

先選定一個目錄做爲Git倉庫，假定是/srv/sample.git，在/srv目錄下輸入命令：

$ sudo git init --bare sample.git

Git就會建立一個裸倉庫，裸倉庫沒有工做區，由於服務器上的Git倉庫純粹是爲了共享，因此不讓用戶直接登陸到服務器上去改工做區，而且服務器上的Git倉庫一般都以.git結尾。而後，把owner改成git：

$ sudo chown -R git:git sample.git

第五步，禁用shell登陸：

出於安全考慮，第二步建立的git用戶不容許登陸shell，這能夠經過編輯/etc/passwd文件完成。找到相似下面的一行：

git:x:1001:1001:,,,:/home/git:/bin/bash

改成：

git:x:1001:1001:,,,:/home/git:/usr/bin/git-shell

這樣，git用戶能夠正常經過ssh使用git，但沒法登陸shell，由於咱們爲git用戶指定的git-shell每次一登陸就自動退出。

第六步，克隆遠程倉庫：

如今，能夠經過git clone命令克隆遠程倉庫了，在各自的電腦上運行：

$ git clone git@server:/srv/sample.git Cloning into 'sample'... warning: You appear to have cloned an empty repository.

剩下的推送就簡單了。

管理公鑰

若是團隊很小，把每一個人的公鑰收集起來放到服務器的/home/git/.ssh/authorized_keys文件裏就是可行的。若是團隊有幾百號人，就無法這麼玩了，這時，能夠用Gitosis來管理公鑰。

這裏咱們不介紹怎麼玩Gitosis了，幾百號人的團隊基本都在500強了，相信找個高水平的Linux管理員問題不大。

管理權限

有不少不但視源代碼如生命，並且視員工爲竊賊的公司，會在版本控制系統裏設置一套完善的權限控制，每一個人是否有讀寫權限會精確到每一個分支甚至每一個目錄下。由於Git是爲Linux源代碼託管而開發的，因此Git也繼承了開源社區的精神，不支持權限控制。不過，由於Git支持鉤子（hook），因此，能夠在服務器端編寫一系列腳原本控制提交等操做，達到權限控制的目的。Gitolite就是這個工具。

這裏咱們也不介紹Gitolite了，不要把有限的生命浪費到權限鬥爭中。