git的使用[轉]

本節内容

github介紹
安裝
倉庫建立& 送出代碼
代碼復原
工作區和暫存區
撤銷修改
删除操作
遠端倉庫
分支管理
多人協作
github使用
忽略特殊檔案.gitignore

為什麼要用版本控制？

假設你在的公司要上線一個新功能，你們開發團隊為實作這個新功能，寫了大約5000行代碼，上線沒2天，就發現這個功能使用者并不喜歡，你老闆讓你去掉這個功能，你怎麼辦？你說簡單，直接把5000行代碼去掉就行了，但是我的親，說的簡單，你的這個功能寫了3周時間，但你還能記得你是新增加了哪5000行代碼麼？是以你急需要一個工具，能幫你記錄每次對代碼做了哪些修改，并且可以輕易的把代碼復原到曆史上的某個狀态。這個神奇的工具就叫做版本控制。

版本控制工具主要實作2個功能：

版本管理

在開發中，這是剛需，必須允許可以很容易對産品的版本進行任意復原，版本控制工具實作這個功能的原理簡單來講，就是你每修改一次代碼，它就幫你做一次快照

協作開發

一個複雜點的軟體，往往不是一個開發人員可以搞定的，公司為加快産品開發速度，會招聘一堆跟你一樣的開發人員開發這個産品，拿微信來舉例，現在假設3個人一起開發微信，A開發聯系人功能，B開發發文字、圖檔、語音通訊功能，C開發視訊通話功能， B和C的功能都是要基于通訊錄的，你說簡單，直接把A開發的代碼copy過來，在它的基礎上開發就好了，可以，但是你在他的代碼基礎上開發了2周後，這期間A沒閑着，對通訊錄代碼作了更新，此時怎麼辦？你和他的代碼不一緻了，此時我們知道，你肯定要再把A的新代碼拿過來替換掉你手上的舊通訊錄功能代碼，現在人少，3個人之間溝通很簡單，但想想，如果團隊變成30個人呢？來回這樣copy代碼，很快就亂了，是以此時亟需一個工具，能確定一直存儲最新的代碼庫，所有人的代碼應該和最新的代碼庫保持一緻

常見版本管理工具介紹

1、VSS-- Visual Source Safe

此工具是Microsoft提供的，是使用的相當普遍的工具之一，他可以與VS.net進行無縫內建，成為了獨立開發人員和小型開發團隊所适合的工具，基本上Window平台上開發的中小型企業，當規模較大後，其性能通常是無法忍受的，對分支與并行開發支援的比較有限。

2、CVS--Concurrent Versions System，

此工具是一個開源工具，與後面提到的SVN是同一個廠家：Collab.Net提供的。

CVS是源于unix的版本控制工具，對于CVS的安裝和使用最好對unix的系統有所了解能更容易學習，CVS的伺服器管理需要進行各種指令行操作。目前，CVS的用戶端有winCVS的圖形化界面，伺服器端也有CVSNT的版本，易用性正在提高。

此工具是相當著名，使用得相當廣泛的版本控制工具之一，使用成熟的“Copy-Modify-Merge"開發模型，可以大大的提高開發效率，适合于項目比較大，産品釋出頻繁，分支活動頻繁的中大型項目。

3、SVN --CollabNet Subversion

此工具是在CVS 的基礎上，由CollabNet提供開發的，也是開源工具,應用比較廣泛。

他修正cvs的一些局限性，适用範圍同cvs，目前有一些基于SVN的第三方工具，如TortoiseSVN,是其用戶端程式，使用的也相當廣泛。在權限管理，分支合并等方面做的很出色，他可以與Apache內建在一起進行使用者認證。

不過在權限管理方面目前還沒有個很好用的界面化工具，SVNManger對于已經使用SVN進行配置的項目來說，基本上是無法應用的，但對于從頭開始的項目是可以的，功能比較強大，但是搭建svnManger比較麻煩。

是一個跨平台的軟體，支援大多數常見的作業系統。作為一個開源的版本控制系統,Subversion 管理着随時間改變的資料。這些資料放置在一個中央資料檔案庫中。這個檔案庫很像一個普通的檔案伺服器, 不過它會記住每一次檔案的變動。這樣你就可以把檔案恢複到舊的版本, 或是浏覽檔案的變動曆史。Subversion 是一個通用的系統, 可用來管理任何類型的檔案, 其中包括了程式源碼。

4. GIT

因為最初是從Linux起家的，非常依賴檔案系統的一些特性，這些在 Linux 下表現的很好，而 Windows 下特别糟糕Git 中文教程

Git是一個開源的分布式版本控制系統，用以有效、高速的處理從很小到非常大的項目版本管理.

Git 是 Linus Torvalds 為了幫助管理 Linux 核心開發而開發的一個開放源碼的版本控制軟體。

Torvalds 開始着手開發 Git 是為了作為一種過渡方案來替代 BitKeeper，後者之前一直是 Linux 核心開發人員在全球使用的主要源代碼工具。開放源碼社群中的有些人覺得 BitKeeper 的許可證并不适合開放源碼社群的工作，是以 Torvalds 決定着手研究許可證更為靈活的版本控制系統。盡管最初 Git 的開發是為了輔助 Linux 核心開發的過程，但是我們已經發現在很多其他自由軟體項目中也使用了 Git。例如最近就遷移到 Git 上來了，很多 Freedesktop 的項目也遷移到了 Git 上。

5、BitKeeper

是由BitMover公司提供的，BitKeeper自稱是“分布式”可擴縮SCM系統。

不是采用C/S結構，而是采用P2P結構來實作的，同樣支援變更任務，所有變更集的操作都是原子的，與svn,cvs一緻。

1.github介紹

很多人都知道，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網站上線了（github是一個基于git的代碼托管平台，付費使用者可以建私人倉庫，我們一般的免費使用者隻能使用公共倉庫，也就是代碼要公開。），它為開源項目免費提供Git存儲，無數開源項目開始遷移至GitHub，包括jQuery，PHP，Ruby等等。

曆史就是這麼偶然，如果不是當年BitMover公司威脅Linux社群，可能現在我們就沒有免費而超級好用的Git了。

今天，GitHub已是：

一個擁有143萬開發者的社群。其中不乏Linux發明者Torvalds這樣的頂級黑客，以及Rails創始人DHH這樣的年輕極客。
這個星球上最流行的開源托管服務。目前已托管431萬git項目，不僅越來越多知名開源項目遷入GitHub，比如Ruby on Rails、jQuery、Ruby、Erlang/OTP；近三年流行的開源庫往往在GitHub首發，例如：BootStrap、Node.js、CoffeScript等。
alexa全球排名414的網站。

2. git安裝

安裝Git

最早Git是在Linux上開發的，很長一段時間内，Git也隻能在Linux和Unix系統上跑。不過，慢慢地有人把它移植到了Windows上。現在，Git可以在Linux、Unix、Mac和Windows這幾大平台上正常運作了。

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

在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的安裝，非常簡單。

3.版本庫建立

什麼是版本庫呢？版本庫又名倉庫，英文名repository，你可以簡單了解成一個目錄，這個目錄裡面的所有檔案都可以被Git管理起來，每個檔案的修改、删除，Git都能跟蹤，以便任何時刻都可以追蹤曆史，或者在将來某個時刻可以“還原”。

是以，建立一個版本庫非常簡單，首先，選擇一個合适的地方，建立一個空目錄：

4 5	`$` `mkdir` `git_trainning` `$` `cd` `git_trainning/` `$ git init` `Initialized empty Git repository` `in` `/Users/alex/git_trainning/` `.git/`

瞬間Git就把倉庫建好了，而且告訴你是一個空的倉庫（empty Git repository），細心的讀者可以發現目前目錄下多了一個

.git

的目錄，這個目錄是Git來跟蹤管理版本庫的，沒事千萬不要手動修改這個目錄裡面的檔案，不然改亂了，就把Git倉庫給破壞了。

如果你沒有看到

.git

ls -ah

指令就可以看見。

把檔案添加到版本庫

首先這裡再明确一下，所有的版本控制系統，其實隻能跟蹤文本檔案的改動，比如TXT檔案，網頁，所有的程式代碼等等，Git也不例外。版本控制系統可以告訴你每次的改動，比如在第5行加了一個單詞“Linux”，在第8行删了一個單詞“Windows”。而圖檔、視訊這些二進制檔案，雖然也能由版本控制系統管理，但沒法跟蹤檔案的變化，隻能把二進制檔案每次改動串起來，也就是隻知道圖檔從100KB改成了120KB，但到底改了啥，版本控制系統不知道，也沒法知道。

不幸的是，Microsoft的Word格式是二進制格式，是以，版本控制系統是沒法跟蹤Word檔案的改動的，前面我們舉的例子隻是為了示範，如果要真正使用版本控制系統，就要以純文字方式編寫檔案。

因為文本是有編碼的，比如中文有常用的GBK編碼，日文有Shift_JIS編碼，如果沒有曆史遺留問題，強烈建議使用标準的UTF-8編碼，所有語言使用同一種編碼，既沒有沖突，又被所有平台所支援。

言歸正傳，現在我們編寫一個first_git_file.txt檔案，内容如下：

$ vim first_git_file.txt

first

time

using git, excited!

第一次用git哈哈

一定要放到git_trainning目錄下（子目錄也行），因為這是一個Git倉庫，放到其他地方Git再厲害也找不到這個檔案。

和把大象放到冰箱需要3步相比，把一個檔案放到Git倉庫隻需要兩步。

第一步，用指令

git add

告訴Git，把檔案添加到倉庫：

$ git add first_git_file.txt

執行上面的指令，沒有任何顯示，說明添加成功。

第二步，用指令

git commit

告訴Git，把檔案送出到倉庫：　　

$ git commit -m

"commit my first git file"

[master (root-commit) 621e6e4] commit my first git

file

Committer: Alex Li <alex@alexs-macbook-pro.

local

Your name and email address were configured automatically based

on your username and

hostname

. Please check that they are accurate.

You can suppress this message by setting them explicitly. Run the

following

command

and follow the instructions

in

your editor to edit

your configuration

file

git config --global --edit

After doing this, you may fix the identity used

for

this commit with:

git commit --amend --reset-author

file

changed, 2 insertions(+)

create mode 100644 first_git_file.txt

/alex

@alexs-macbook-pro.

local

中間紅色部分的意思是，你在往git庫裡送出代碼時，你需要告訴git你是誰，這樣git就會紀錄下來是誰改的代碼，其實就是為了日後查詢友善，你隻需要提供一個名字和郵件位址就可以，這裡我的git直接通過主機名自己建立了一個，但你可以通過git config --global --edit修改

簡單解釋一下

git commit

指令，

-m

後面輸入的是本次送出的說明，可以輸入任意内容，當然最好是有意義的，這樣你就能從曆史記錄裡友善地找到改動記錄。

嫌麻煩不想輸入

-m "xxx"

行不行？确實有辦法可以這麼幹，但是強烈不建議你這麼幹，因為輸入說明對自己對别人閱讀都很重要。

為什麼Git添加檔案需要

add

，

commit

一共兩步呢？因為

commit

可以一次送出很多檔案，是以你可以多次

add

不同的檔案，比如：

$ git add file1.txt

$ git add file2.txt file3.txt

$ git commit -m

"add 3 files."

4. 代碼復原

4.1代碼修改并送出　　

我們已經成功地添加并送出了一個first_git_file.txt檔案，現在，是時候繼續工作了，于是，我們繼續修改first_git_file.txt檔案，改成如下内容：

First

time

using git, excited! update ...

insert line here...

第一次用git哈哈

現在，運作

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:   first_git_file.txt

no changes added to commit (use

"git add"

and

/or

"git commit -a"

雖然Git告訴我們first_git_file.txt被修改了，但如果能看看具體修改了什麼内容，自然是很好的。比如你休假兩周從國外回來，第一天上班時，已經記不清上次怎麼修改的readme.txt，是以，需要用

git diff

這個指令看看：　　

$ git

diff

first_git_file.txt

diff

--git a

/first_git_file

.txt b

/first_git_file

.txt

index 2d13c2c..248d853 100644

--- a

/first_git_file

.txt

+++ b

/first_git_file

.txt

@@ -1,3 +1,4 @@

-first

time

using git, excited!

+First

time

using git, excited! update ...

insert line here...

第一次用git哈哈

+insert line again haha...

輸出中＋号綠色顯示的就是修改或新增的内容，－号紅色顯示的就是去掉或被修改的内容

知道了對first_git_file.txt 作了什麼修改後，再把它送出到倉庫就放心多了，送出修改和送出新檔案是一樣的兩步，第一步是

git add

：

$ git add .

# .  代表把目前目錄下所有改動的檔案都送出到代碼庫

Alexs-MacBook-Pro:git_trainning alex$ git commit -m

"commit changes"

[master 50ad6b5] commit changes

Committer: Alex Li <alex@Alexs-MacBook-Pro.

local

file

changed, 1 insertion(+)

送出後，我們再用

git status

指令看看倉庫的目前狀态：　　

$ git status

# On branch master

nothing to commit (working directory clean)

Git告訴我們目前沒有需要送出的修改，而且，工作目錄是幹淨（working directory clean）的。

4.2 代碼復原　　

現在，你已經學會了修改檔案，然後把修改送出到Git版本庫，現在，再練習一次，修改first_git_file.txtt檔案如下：

First

time

using git, excited! update ...

insert line here..改之前的.

第一次用git哈哈

insert line again haha...

加點新内容

然後嘗試送出：

$ git add first_git_file.txt

$ git commit -m

"add new content"

[master 4459657] add new content

Committer: Alex Li <alex@Alexs-MacBook-Pro.

local

file

changed, 2 insertions(+), 1 deletion(-)

像這樣，你不斷對檔案進行修改，然後不斷送出修改到版本庫裡，就好比玩RPG遊戲時，每通過一關就會自動把遊戲狀态存盤，如果某一關沒過去，你還可以選擇讀取前一關的狀态。有些時候，在打Boss之前，你會手動存盤，以便萬一打Boss失敗了，可以從最近的地方重新開始。Git也是一樣，每當你覺得檔案修改到一定程度的時候，就可以“儲存一個快照”，這個快照在Git中被稱為

commit

。一旦你把檔案改亂了，或者誤删了檔案，還可以從最近的一個

commit

恢複，然後繼續工作，而不是把幾個月的工作成果全部丢失。

現在，我們回顧一下first_git_file.txt檔案一共有幾個版本被送出到Git倉庫裡了：

版本1

first

time

using git, excited!

第一次用git哈哈

版本2

first

time

using git, excited!

insert line here...

第一次用git哈哈

版本3

first

time

using git, excited!

insert line here...

第一次用git哈哈

insert line again haha...

版本4

First

time

using git, excited! update ...

insert line here..改之前的.

第一次用git哈哈

insert line again haha...

加點新内容

當然了，在實際工作中，我們腦子裡怎麼可能記得一個幾千行的檔案每次都改了什麼内容，不然要版本控制系統幹什麼。版本控制系統肯定有某個指令可以告訴我們曆史記錄，在Git中，我們用

git log

指令檢視：

$ git log

commit 445965781d1fd0d91e76d120450dd18fd06c7489

Author: Alex Li <alex@Alexs-MacBook-Pro.

local

Date:   Tue Oct 4 18:44:29 2016 +0800

add new content

commit be02137bb2f54bbef0c2e99202281b3966251952

Author: Alex Li <alex@Alexs-MacBook-Pro.

local

Date:   Tue Oct 4 17:55:16 2016 +0800

update again

commit 50ad6b526810bb7ccfea430663757ba2337b9816

Author: Alex Li <alex@Alexs-MacBook-Pro.

local

Date:   Tue Oct 4 17:46:51 2016 +0800

commit changes

commit 621e6e44d04fa6a1cdc37826f01efa61b451abd1

Author: Alex Li <alex@Alexs-MacBook-Pro.

local

Date:   Tue Oct 4 17:42:50 2016 +0800

commit my first git

file

git log

指令顯示從最近到最遠的送出日志，我們可以看到4次送出，最近的一次是add new content，上一次是update again，最早的一次是

commit my first git file

。如果嫌輸出資訊太多，看得眼花缭亂的，可以試試加上

--pretty=oneline

參數：　　

$ git log --pretty=oneline

445965781d1fd0d91e76d120450dd18fd06c7489 add new content

be02137bb2f54bbef0c2e99202281b3966251952 update again

50ad6b526810bb7ccfea430663757ba2337b9816 commit changes

621e6e44d04fa6a1cdc37826f01efa61b451abd1 commit my first git

file

需要友情提示的是，你看到的一大串類似

3628164...882e1e0

的是

commit id

（版本号），和SVN不一樣，Git的

commit id

不是1，2，3……遞增的數字，而是一個SHA1計算出來的一個非常大的數字，用十六進制表示，而且你看到的

commit id

和我的肯定不一樣，以你自己的為準。為什麼

commit id

需要用這麼一大串數字表示呢？因為Git是分布式的版本控制系統，後面我們還要研究多人在同一個版本庫裡工作，如果大家都用1，2，3……作為版本号，那肯定就沖突了。　　

復原復原復原　　

好了，現在我們啟動時光穿梭機，準備把first_git_file.txt回退到上一個版本，也就是“update again”的那個版本，怎麼做呢？

首先，Git必須知道目前版本是哪個版本，在Git中，用

HEAD

表示目前版本，也就是最新的送出be02137bb2f54bbef0c2e99202281b3966251952（注意我的送出ID和你的肯定不一樣），上一個版本就是

HEAD^

，上上一個版本就是

HEAD^^

，當然往上100個版本寫100個

比較容易數不過來，是以寫成

HEAD~100

。

現在，我們要把目前版本“add new content”回退到上一個版本“update again”，就可以使用

git reset

指令：

$ git reset --hard HEAD^

HEAD is now at be02137 update again

此時再看你的檔案内容，果然就退回去了

more

first_git_file.txt

First

time

using git, excited! update ...

insert line here...

第一次用git哈哈

insert line again haha...

此時還可以繼續再往前回退一個版本，不過且慢，然我們用

git log

再看看現在版本庫的狀态：

$ git log --pretty=oneline

be02137bb2f54bbef0c2e99202281b3966251952 update again

50ad6b526810bb7ccfea430663757ba2337b9816 commit changes

621e6e44d04fa6a1cdc37826f01efa61b451abd1 commit my first git

file

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

辦法其實還是有的，隻要上面的指令行視窗還沒有被關掉，你就可以順着往上找啊找啊，找到那個add new content的

commit id

是445965781d1fd0d91e76d120450dd18fd06c7489

，于是就可以指定回到未來的某個版本：

git reset --hard 4459657

HEAD is now at 4459657 add new content

版本号沒必要寫全，前幾位就可以了，Git會自動去找。當然也不能隻寫前一兩位，因為Git可能會找到多個版本号，就無法确定是哪一個了。

再小心翼翼地看看first_git_file.txt的内容：

First

time

using git, excited! update ...

insert line here..改之前的.

第一次用git哈哈

insert line again haha...

加點新内容

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

Git的版本回退速度非常快，因為Git在内部有個指向目前版本的

HEAD

指針，當你回退版本的時候，Git僅僅是把HEAD從指向

add new content

現在，你回退到了某個版本，關掉了電腦，第二天早上就後悔了，想恢複到新版本怎麼辦？找不到新版本的commit id怎麼辦？

在Git中，總是有後悔藥可以吃的。當你用$ git reset --hard HEAD^回退到update again版本時，再想恢複到最新add new content的版本，就必須找到add new contentL的commit id。Git提供了一個指令git reflog用來記錄你的每一次指令：

$ git reflog

4459657 HEAD@{0}: reset: moving to 4459657

be02137 HEAD@{1}: reset: moving to HEAD^

4459657 HEAD@{2}: commit: add new content

be02137 HEAD@{3}: reset: moving to be02137bb

50ad6b5 HEAD@{4}: reset: moving to 50ad6b5

621e6e4 HEAD@{5}: reset: moving to 621e6e44

50ad6b5 HEAD@{6}: reset: moving to HEAD^

be02137 HEAD@{7}: commit: update again

50ad6b5 HEAD@{8}: commit: commit changes

621e6e4 HEAD@{9}: commit (initial): commit my first git

file

終于舒了口氣，第二行顯示

add new content

的commit id是4459657，現在，你又可以乘坐時光機回到未來了。　　

5. 工作區和暫存區

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

先來看名詞解釋。

工作區（Working Directory）

就是你在電腦裡能看到的目錄，比如我的git_trainning檔案夾就是一個工作區：

ls

git_trainning/

first_git_file.txt

版本庫（Repository）

工作區有一個隐藏目錄

.git

，這個不算工作區，而是Git的版本庫。

Git的版本庫裡存了很多東西，其中最重要的就是稱為stage（或者叫index）的暫存區，還有Git為我們自動建立的第一個分支

master

，以及指向

master

的一個指針叫

HEAD

分支和

HEAD

的概念我們以後再講。

前面講了我們把檔案往Git版本庫裡添加的時候，是分兩步執行的：

第一步是用

git add

把檔案添加進去，實際上就是把檔案修改添加到暫存區；

第二步是用

git commit

送出更改，實際上就是把暫存區的所有内容送出到目前分支。

因為我們建立Git版本庫時，Git自動為我們建立了唯一一個

master

分支，是以，現在，

git commit

就是往

master

分支上送出更改。

你可以簡單了解為，需要送出的檔案修改通通放到暫存區，然後，一次性送出暫存區的所有修改。

俗話說，實踐出真知。現在，我們再練習一遍，先對

first_git_file.txt

做個修改，比如加上一行内容：

First

time

using git, excited! update ...

insert line here..改之前的.

第一次用git哈哈

insert line again haha...

加點新内容

update v5

然後，在工作區新增一個

readme.md

文本檔案（内容随便寫）。

先用

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:   first_git_file.txt

Untracked files:

(use

"git add <file>..."

to include

in

what will be committed)

readme.md

no changes added to commit (use

"git add"

and

/or

"git commit -a"

Git非常清楚地告訴我們，

first_git_file.txt

被修改了，而

readme.md

還從來沒有被添加過，是以它的狀态是

Untracked

現在，使用指令

git add .

，再用

git status

再檢視一下：

$ git add .

$ git status

On branch master

Changes to be committed:

(use

"git reset HEAD <file>..."

to unstage)

modified:   first_git_file.txt

new

file

:   readme.md

/file

現在，暫存區的狀态就變成這樣了：

(盜圖關系，這裡readme.txt = first_git_file.txt , LICENSE = readme.md)

是以，

git add

指令實際上就是把要送出的所有修改放到暫存區（Stage），然後，執行

git commit

就可以一次性把暫存區的所有修改送出到分支。

$ git commit -m

"知道暫存區stage的意思了"

[master 9d65cb2] 知道暫存區stage的意思了

2 files changed, 2 insertions(+)

create mode 100644 readme.md

一旦送出後，如果你又沒有對工作區做任何修改，那麼工作區就是“幹淨”的：

$ git status

On branch master

nothing to commit, working directory clean

現在版本庫變成了這樣，暫存區就沒有任何内容了：

暫存區是Git非常重要的概念，弄明白了暫存區，就弄明白了Git的很多操作到底幹了什麼。

6. 撤銷修改　　

自然，你是不會犯錯的。不過現在是淩晨兩點，你正在趕一份工作報告，你在

readme.md

中添加了一行：

#git study repo

git is great

but 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.md

no changes added to commit (use

"git add"

and

/or

"git commit -a"

/file

><

/file

你可以發現，Git會告訴你，

git checkout -- file

可以丢棄工作區的修改：　　

$ git checkout -- readme.md

more

readme.md

#git study repo

你剛才添加的2行罵老闆的話就被撤銷了，

指令

git checkout -- readme.md

意思就是，把

readme.md

檔案在工作區的修改全部撤銷，這裡有兩種情況：

一種是

readme.md

自修改後還沒有被放到暫存區，現在，撤銷修改就回到和版本庫一模一樣的狀态；

readme.md

已經添加到暫存區後，又作了修改，現在，撤銷修改就回到添加到暫存區後的狀态。

總之，就是讓這個檔案回到最近一次

git commit

或

git add

時的狀态。

git checkout -- file

指令中的

--

很重要，沒有

--

，就變成了“切換到另一個分支”的指令，我們在後面的分支管理中會再次遇到

git checkout

指令。　　

現在假定是淩晨3點，你不但寫了一些胡話，還

git add

到暫存區了：

cat

readme.md

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.md

慶幸的是，在

commit

之前，你發現了這個問題。用

git status

檢視一下，修改隻是添加到了暫存區，還沒有送出：

$ git status

On branch master

Changes to be committed:

(use

"git reset HEAD <file>..."

to unstage)

modified:   readme.md

/file

Git同樣告訴我們，用指令

git reset HEAD file

可以把暫存區的修改撤銷掉（unstage），重新放回工作區：

$ git reset HEAD readme.md

Unstaged changes after reset:

M   readme.md

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.md

no changes added to commit (use

"git add"

and

/or

"git commit -a"

還記得如何丢棄工作區的修改嗎？

$ git checkout -- readme.md

more

readme.md

#git study repo

整個世界終于清靜了！

7. 删除操作

在Git中，删除也是一個修改操作，我們實戰一下，先添加一個新檔案test.txt到Git并且送出：　　

$ git add .

$ git commit -m

"add test.txt"

[master a8fa95a] add

test

.txt

file

changed, 0 insertions(+), 0 deletions(-)

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

x$ git

rm

test

.txt

rm

'test.txt'

$ git commit -m

"remove test"

[master 03df00a] remove

test

file

changed, 0 insertions(+), 0 deletions(-)

delete mode 100644

test

.txt

現在，檔案就從版本庫中被删除了。

另一種情況是删錯了，因為版本庫裡還有呢，是以可以很輕松地把誤删的檔案恢複到最新版本：

$ git checkout --

test

.txt

git checkout

其實是用版本庫裡的版本替換工作區的版本，無論工作區是修改還是删除，都可以“一鍵還原”。　　

8. 遠端倉庫　　

到目前為止，我們已經掌握了如何在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

"[email protected]"

你需要把郵件位址換成你自己的郵件位址，然後一路回車，使用預設值即可，由于這個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賬号後，我們就即将開始遠端倉庫的學習。

8.1 建立遠端倉庫

現在的情景是，你已經在本地建立了一個Git倉庫後，又想在GitHub建立一個Git倉庫，并且讓這兩個倉庫進行遠端同步，這樣，GitHub上的倉庫既可以作為備份，又可以讓其他人通過該倉庫來協作，真是一舉多得。

首先，登陸GitHub，然後，在右上角找到“New repository”按鈕，建立一個新的倉庫：

建立好的倉庫

目前，在GitHub上的這個oldboy_website倉庫還是空的，GitHub告訴我們，可以從這個倉庫克隆出新的倉庫，也可以把一個已有的本地倉庫與之關聯，然後，把本地倉庫的内容推送到GitHub倉庫。

現在，我們根據GitHub的提示，在本地已有的git_trainning倉庫下運作指令：

$ git remote add origin [email protected]:triaquae

/oldboy_website

.git ＃添加遠端倉庫

$ git push -u origin master

#推到遠端

The authenticity of host

'github.com (192.30.253.113)'

can't be established.

RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.

Are you sure you want to

continue

connecting (

yes

/no

)?

yes

#第一次推會出現，寫yes

Warning: Permanently added

'github.com,192.30.253.113'

(RSA) to the list of known hosts.

Counting objects: 20,

done

Delta compression using up to 8 threads.

Compressing objects: 100% (14

/14

),

done

Writing objects: 100% (20

/20

), 1.76 KiB | 0 bytes

/s

done

Total 20 (delta 4), reused 0 (delta 0)

remote: Resolving deltas: 100% (4

/4

),

done

To [email protected]:triaquae

/oldboy_website

.git

* [new branch]      master -> master

Branch master

set

up to track remote branch master from origin.

請千萬注意，把上面的triaquae替換成你自己的GitHub賬戶名，否則，你在本地關聯的就是我的遠端庫，關聯沒有問題，但是你以後推送是推不上去的，因為你的SSH Key公鑰不在我的賬戶清單中。

添加後，遠端庫的名字就是

origin

，這是Git預設的叫法，也可以改成别的，但是

origin

這個名字一看就知道是遠端庫。

把本地庫的内容推送到遠端，用

git push

指令，實際上是把目前分支

master

推送到遠端。　　

此時重新整理遠端倉庫頁面，就看到了你剛從本地推上來的代碼了

從現在起，隻要本地作了送出，就可以通過指令：

$ git push origin master

what ? 不信？那幫你試一下吧

建立一個index.html檔案，同時上傳到遠端

$ vim index.html

$ git add .

$ git commit -m

"add home page"

[master 8675486] add home page

file

changed, 6 insertions(+)

create mode 100644 index.html

$ git push origin master

#推到遠端

Counting objects: 3,

done

Delta compression using up to 8 threads.

Compressing objects: 100% (3

/3

),

done

Writing objects: 100% (3

/3

), 362 bytes | 0 bytes

/s

done

Total 3 (delta 0), reused 0 (delta 0)

To [email protected]:triaquae

/oldboy_website

.git

03df00a..8675486  master -> master

然後重新整理下遠端倉庫頁面，就看到你的新建立的檔案了

8.2 從遠端庫克隆　　

我們講了先有本地庫，後有遠端庫的時候，如何關聯遠端庫。

現在，假設我們從零開發，那麼最好的方式是先建立遠端庫，然後，從遠端庫克隆。

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

gitskills

我們勾選

Initialize this repository with a README

，這樣GitHub會自動為我們建立一個

README.md

檔案。建立完畢後，可以看到

README.md

檔案：

現在，遠端庫已經準備好了，下一步是用指令

git clone

克隆一個本地庫：

在本地找一個你想存放這個遠端倉庫的目錄，然後在本地指令行用git clone 指令來克隆這個遠端庫

$ git clone [email protected]:triaquae

/gitskills

.git

Cloning into

'gitskills'

...

Warning: Permanently added the RSA host key

for

IP address

'192.30.253.112'

to the list of known hosts.

remote: Counting objects: 3,

done

remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0

Receiving objects: 100% (3

/3

),

done

Checking connectivity...

done

cd

gitskills/

#進入剛clone下來的目錄

ls

README.md

如果有多個人協作開發，那麼每個人各自從遠端克隆一份就可以了。

你也許還注意到，GitHub給出的位址不止一個，還可以用https://github.com/triaquae/gitskills.git 這樣的位址。實際上，Git支援多種協定，預設的

git://

使用ssh，但也可以使用

https

等其他協定。

使用

https

除了速度慢以外，還有個最大的麻煩是每次推送都必須輸入密碼，但是在某些隻開放http端口的公司内部就無法使用

ssh

協定而隻能用

https

9. 分支管理　　

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

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

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

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

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

但Git的分支是與衆不同的，無論建立、切換和删除分支，Git在1秒鐘之内就能完成！無論你的版本庫是1個檔案還是1萬個檔案。

9.1 建立與合并分支

在學習版本回退部分時，你已經知道，每次送出，Git都把它們串成一條時間線，這條時間線就是一個分支。截止到目前，隻有一條時間線，在Git裡，這個分支叫主分支，即

master

分支。

HEAD

嚴格來說不是指向送出，而是指向

master

master

才是指向送出的，是以，

HEAD

指向的就是目前分支。

一開始的時候，

master

分支是一條線，Git用

master

指向最新的送出，再用

HEAD

指向

master

，就能确定目前分支，以及目前分支的送出點：

每次送出，

master

分支都會向前移動一步，這樣，随着你不斷送出，

master

分支的線也越來越長，當我們建立新的分支，例如

dev

時，Git建立了一個指針叫

dev

，指向

master

相同的送出，再把

HEAD

dev

，就表示目前分支在

dev

上：

假如我們在

dev

上的工作完成了，就可以把

dev

合并到

master

上。Git怎麼合并呢？最簡單的方法，就是直接把

master

dev

的目前送出，就完成了合并：

是以Git合并分支也很快！就改改指針，工作區内容也不變！

合并完分支後，甚至可以删除

dev

分支。删除

dev

分支就是把

dev

指針給删掉，删掉後，我們就剩下了一條

master

分支：

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

下面開始實戰。

首先，我們建立

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 fec145a] branch

test

file

changed, 1 insertion(+)

現在，

dev

分支的工作完成，我們就可以切換回

master

$ git checkout master

Switched to branch

'master'

切換回

master

分支後，再檢視一個readme.txt檔案，剛才添加的内容不見了！因為那個送出是在

dev

分支上，而

master

分支此刻的送出點并沒有變：

現在，我們把

dev

分支的工作成果合并到

master

分支上：

$ git merge dev

Updating d17efd8..fec145a

Fast-forward

readme.txt |    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 fec145a).

删除後，檢視

branch

，就隻剩下

master

$ git branch

* master

因為建立、合并和删除分支非常快，是以Git鼓勵你使用分支完成某個任務，合并後再删掉分支，這和直接在

master

分支上工作效果是一樣的，但過程更安全。

9.2 解決沖突

人生不如意之事十之八九，合并分支往往也不是一帆風順的。

準備新的

feature1

分支，繼續我們的新分支開發：

$ git checkout -b feature1

Switched to a new branch

'feature1'

修改readme.txt最後一行，改為：

added this line from branch feature 1

在

feature1

分支上送出：

$ git add readme.txt 
$ git commit -m "add feature"
[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還會自動提示我們目前

master

分支比遠端的

master

分支要超前1個送出。

master

分支上把readme.txt檔案的最後一行改為：

added this line from master

送出：

$ git add readme.txt 
$ git commit -m "master update"
[master 400b400] & 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.

# Unmerged paths:

#   (use "git add/rm <file>..." as appropriate to mark resolution)

#       both modified:      readme.txt

no changes added to commit (use

"git add"

and

/or

"git commit -a"

我們可以直接檢視readme.txt的内容：

#git study repo

Creating a new branch is quick.

<<<<<<< HEAD

added this line from master

=======

added this line from branch feature 1

>>>>>>> feature1

Git用

<<<<<<<

=======

>>>>>>>

标記出不同分支的内容，我們修改如下後儲存：

#git study repo

Creating a new branch is quick.

added this line from master

added this line from branch feature 1

再送出

$ git add readme.txt

$ git commit -m

"conflict fixed"

[master 59bc1cb] conflict fixed

master

feature1

分支變成了下圖所示：

用帶參數的

git log

也可以看到分支的合并情況：

$ git log --graph --pretty=oneline

*   feedd786cad3e18323a41846fcc1b0d52fc0c98e fix conflict

|\

| * 01f8f8d168e113fac9fbe24c4cfa6d4c351a9821 update from branch

* | 743ccee30f3d74f1993f17e7312032b7399b1306 from master

|/

* edfbc29982927236596539e0f1971b0575f803c0 branch

test

* 8675486bfeeb340914369e80d2cfcf3e854e88a3 add home page

9.3 分支政策

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

首先，

master

分支應該是非常穩定的，也就是僅用來釋出新版本，平時不能在上面幹活；

那在哪幹活呢？幹活都在

dev

分支上，也就是說，

dev

分支是不穩定的，到某個時候，比如1.0版本釋出時，再把

dev

分支合并到

master

上，在

master

分支釋出1.0版本；

你和你的小夥伴們每個人都在

dev

分支上幹活，每個人都有自己的分支，時不時地往

dev

分支上合并就可以了。

是以，團隊合作的分支看起來就像這樣：

9.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: 6224937 add merge

HEAD is now at 6224937 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.

$ 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 cc17032] fix bug 101

file

changed, 1 insertion(+), 1 deletion(-)

修複完成後，切換到

master

分支，并完成合并，最後删除

issue-101

$ 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-101

Merge made by the

'recursive'

strategy.

readme.txt |    2 +-

file

changed, 1 insertion(+), 1 deletion(-)

$ git branch -d issue-101

Deleted branch issue-101 (was cc17032).

太棒了，原計劃兩個小時的bug修複隻花了5分鐘！現在，是時候接着回到

dev

分支幹活了！

$ git checkout dev

Switched to branch

'dev'

$ git status

# On branch dev

nothing to commit (working directory clean)

工作區是幹淨的，剛才的工作現場存到哪去了？用

git stash list

指令看看：

$ git stash list

stash@{0}: WIP on dev: 6224937 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} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)

git stash list

檢視，就看不到任何stash内容了：

$ git stash list

你可以多次stash，恢複的時候，先用

git stash list

檢視，然後恢複指定的stash，用指令：

$ git stash apply stash@{0}

10. 多人協作　　

當你從遠端倉庫克隆時，實際上Git自動把本地的

master

分支和遠端的

master

分支對應起來了，并且，遠端倉庫的預設名稱是

origin

要檢視遠端庫的資訊，用

git remote

$ git remote

origin

或者，用

git remote -v

顯示更詳細的資訊：

$ git remote -

origin  [email protected]:triaquae

/gitskills

.git (fetch)

origin  [email protected]:triaquae

/gitskills

.git (push)

上面顯示了可以抓取和推送的

origin

的位址。如果沒有推送權限，就看不到push的位址。

10.1 推送分支

推送分支，就是把該分支上的所有本地送出推送到遠端庫。推送時，要指定本地分支，這樣，Git就會把該分支推送到遠端庫對應的遠端分支上：

$ git push origin master

如果要推送其他分支，比如

dev

，就改成：

$ git push origin dev

但是，并不是一定要把本地分支往遠端推送，那麼，哪些分支需要推送，哪些不需要呢？

master 分支是主分支，是以要時刻與遠端同步；
dev 分支是開發分支，團隊所有成員都需要在上面工作，是以也需要與遠端同步；
bug分支隻用于在本地修複bug，就沒必要推到遠端了，除非老闆要看看你每周到底修複了幾個bug；
feature分支是否推到遠端，取決于你是否和你的小夥伴合作在上面開發。

總之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，視你的心情而定！

10.2 抓取分支

多人協作時，大家都會往

master

dev

分支上推送各自的修改。

現在，模拟一個你的小夥伴，可以在另一台電腦（注意要把SSH Key添加到GitHub）或者同一台電腦的另一個目錄下克隆：

$ git clone [email protected]:triaquae

/gitskills

.git

Cloning into

'gitskills'

...

remote: Counting objects: 16,

done

remote: Compressing objects: 100% (7

/7

),

done

remote: Total 16 (delta 0), reused 10 (delta 0), pack-reused 0

Receiving objects: 100% (16

/16

),

done

Checking connectivity...

done

當你的小夥伴從遠端庫clone時，預設情況下，你的小夥伴隻能看到本地的

master

分支。不信可以用

git branch

$ git branch

* master

現在，你的小夥伴要在

dev

分支上開發，就必須建立遠端

origin

的

dev

分支到本地，于是他用這個指令建立本地

dev

$ git checkout -b dev origin

/dev

現在，他就可以在

dev

上繼續修改，然後，時不時地把

dev

分支

push

到遠端：

$ git add .

$ git commit -m

"small updates"

[dev f1b762e] small updates

2 files changed, 5 insertions(+), 1 deletion(-)

Alexs-MacBook-Pro:gitskills alex$ git push origin dev

Counting objects: 4,

done

Delta compression using up to 8 threads.

Compressing objects: 100% (3

/3

),

done

Writing objects: 100% (4

/4

), 438 bytes | 0 bytes

/s

done

Total 4 (delta 0), reused 0 (delta 0)

To [email protected]:triaquae

/gitskills

.git

33ec6b4..f1b762e  dev -> dev

你的小夥伴已經向origin/dev分支推送了他的送出，而碰巧你也對同樣的檔案作了修改，并試圖推送:

$ git add .

$ git commit -m

"add Dog class"

[dev 7e7b1bf] add Dog class

2 files changed, 7 insertions(+)

$ git push origin dev

To [email protected]:triaquae

/gitskills

.git

! [rejected]        dev -> dev (fetch first)

error: failed to push some refs to

'[email protected]:triaquae/gitskills.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.

推送失敗，因為你的小夥伴的最新送出和你試圖推送的送出有沖突，解決辦法也很簡單，Git已經提示我們，先用

git pull

把最新的送出從

origin/dev

抓下來，然後，在本地合并，解決沖突，再推

$ git pull

remote: Counting objects: 4,

done

remote: Compressing objects: 100% (3

/3

),

done

remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0

Unpacking objects: 100% (4

/4

),

done

From github.com:triaquae

/gitskills

33ec6b4..f1b762e  dev        -> origin

/dev

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 hello.py

CONFLICT (content): Merge conflict

in

hello.py

Auto-merging branch_test.md

CONFLICT (content): Merge conflict

in

branch_test.md

Automatic merge failed; fix conflicts and

then

commit the result.

這回

git pull

成功，但是合并有沖突，需要手動解決，解決的方法和分支管理中的解決沖突完全一樣。解決後，送出，再push：　　

$ git add .

$ git commit -m

"merge & fix hello.py"

[dev 93e28e3] merge & fix hello.py

$ git push origin dev

Counting objects: 8,

done

Delta compression using up to 8 threads.

Compressing objects: 100% (7

/7

),

done

Writing objects: 100% (8

/8

), 819 bytes | 0 bytes

/s

done

Total 8 (delta 1), reused 0 (delta 0)

remote: Resolving deltas: 100% (1

/1

),

done

To [email protected]:triaquae

/gitskills

.git

f1b762e..93e28e3  dev -> dev

是以，多人協作的工作模式通常是這樣：

首先，可以試圖用 git push origin branch-name 推送自己的修改；
如果推送失敗，則因為遠端分支比你的本地更新，需要先用 git pull 試圖合并；
如果合并有沖突，則解決沖突，并在本地送出；
沒有沖突或者解決掉沖突後，再用 git push origin branch-name 推送就能成功！

如果

git pull

提示“no tracking information”，則說明本地分支和遠端分支的連結關系沒有建立，用指令

git branch --set-upstream branch-name origin/branch-name

這就是多人協作的工作模式，一旦熟悉了，就非常簡單。

11. github使用

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

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

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

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

git clone [email protected]:michaelliao

/bootstrap

.git

一定要從自己的賬号下clone倉庫，這樣你才能推送修改。如果從bootstrap的作者的倉庫位址

[email protected]:twbs/bootstrap.git

克隆，因為沒有權限，你将不能推送修改。

Bootstrap的官方倉庫

twbs/bootstrap

、你在GitHub上克隆的倉庫

my/bootstrap

，以及你自己克隆到本地電腦的倉庫，他們的關系就像下圖顯示的那樣：

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

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

如果你沒能力修改bootstrap，但又想要試一把pull request，那就Fork一下我的倉庫：https://github.com/triaquae/gitskills ，建立一個

your-github-id.txt

的文本檔案，寫點自己學習Git的心得，然後推送一個pull request給我，我會視心情而定是否接受。

小結

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

12. 忽略特殊檔案.gitignore

有些時候，你必須把某些檔案放到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 -

App.class

.gitignore:3:*.class    App.class

Git會告訴我們，

.gitignore

的第3行規則忽略了該檔案，于是我們就可以知道應該修訂哪個規則。

忽略某些檔案時，需要編寫 .gitignore ；
.gitignore 檔案本身要放到版本庫裡，并且可以對 .gitignore 做版本管理！

以上文章大量參考或轉載自:

http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000

http://www.cnblogs.com/alex3714/articles/5930846.html

作者：前程明亮

出處：http://www.cnblogs.com/0zcl

文章未标明轉載則為原創部落格。歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利.

1.非系統的學習也是在浪費時間

2.做一個會欣賞美，懂藝術，會藝術的技術人