Git學習總結

阿新 • • 發佈：2020-07-25

更要命的是，有些部分需要你的財務同事幫助填寫，於是你把檔案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世紀。

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！

3.建立版本庫

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

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

新增檔案到Git倉庫，分兩步：

使用命令git add <file>，注意，可反覆多次使用，新增多個檔案；
使用命令git commit -m <message>，完成。

# 新增指定檔案到暫存區
$ git add [file1] [file2] ...
 
# 新增指定目錄到暫存區，包括子目錄
$ git add [dir]
 
# 添加當前目錄的所有檔案到暫存區
$ git add .

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

建立一個版本庫非常簡單：

首先，選擇一個合適的地方，建立一個空目錄(linux),在window下建立一個空資料夾，

第二步，通過git init命令把這個目錄變成Git可以管理的倉庫：

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

瞬間Git就把倉庫建好了，而且告訴你是一個空的倉庫（empty Git repository），細心的讀者可以發現當前目錄下多了一個.git的目錄，這個目錄是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) 3c27ed1] 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有兩行內容）。

4.版本回退

HEAD指向的版本就是當前版本，因此，Git允許我們在版本的歷史之間穿梭，使用命令git reset --hard commit_id。
git reset --hard HEAD^（回前一個版本）
git reset --hard HEAD^^（回前兩個版本）

穿梭前，用git log可以檢視提交歷史，以便確定要回退到哪個版本。

要重返未來，用git reflog檢視命令歷史，以便確定要回到未來的哪個版本。

有關git reset的詳細解釋可看：Git實用教程(小甲魚)

現在，你已經學會了修改檔案，然後把修改提交到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 "under GPL"
[master 1094adb] under 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命令顯示從最近到最遠的提交日誌，我們可以看到3次提交，最近的一次是under GPL，上一次是add distributed，最早的一次是wrote a readme file。

如果嫌輸出資訊太多，看得眼花繚亂的，可以試試加上--pretty=oneline引數：

需要友情提示的是，你看到的一大串類似c1bob622....的是commit id（版本號），和SVN不一樣，Git的commit id不是1，2，3……遞增的數字，而是一個SHA1計算出來的一個非常大的數字，用十六進位制表示，而且你看到的commit id和我的肯定不一樣，以你自己的為準。為什麼commit id需要用這麼一大串數字表示呢？因為Git是分散式的版本控制系統，後面我們還要研究多人在同一個版本庫裡工作，如果大家都用1，2，3……作為版本號，那肯定就衝突了。

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

首先，Git必須知道當前版本是哪個版本，在Git中，用HEAD表示當前版本，也就是最新的提交c1b0b622....（注意我的提交ID和你的肯定不一樣），上一個版本就是HEAD^，上上一個版本就是HEAD^^，當然往上100個版本寫100個^比較容易數不過來，所以寫成HEAD~100。

現在，我們要把當前版本under GPL回退到上一個版本add distributed，就可以使用git reset命令：

--hard引數有啥意義？這個後面再講，現在你先放心使用。

還可以繼續回退到上一個版本wrote a readme file，不過且慢，然我們用git log再看看現在版本庫的狀態：

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

辦法其實還是有的，只要上面的命令列視窗還沒有被關掉，你就可以順著往上找啊找啊，找到那個under GPL的commit id是c1b0b622....，於是就可以指定回到未來的某個版本：

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

Git的版本回退速度非常快，因為Git在內部有個指向當前版本的HEAD指標，當你回退版本的時候，Git僅僅是把HEAD從指向under GPL：

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

改為指向add distributed：

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

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

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

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

從輸出可知，under GPL的commit id是c1b0b62，現在，你又可以乘坐時光機回到未來了

5.工作區和本地倉庫

工作區（Working Directory）

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

本地倉庫(也可以成為版本庫)（Repository）

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

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

因為我們建立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非常清楚地告訴我們，readme.txt被修改了，而LICENSE還從來沒有被新增過，所以它的狀態是Untracked。

現在，使用命令git add，把readme.txt和LICENSE.txt都新增後，用git status再檢視一下：

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

git add命令：實際上就是把要提交的所有修改放到暫存區（Stage）

git commit：就可以一次性把暫存區的所有修改提交到分支。

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

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

6.管理修改

有關git diff命令的更詳細解釋，看B站：Git實用教程(小甲魚)

下面，我們要討論的就是，為什麼Git比其他版本控制系統設計得優秀，因為Git跟蹤並管理的是修改，而非檔案。

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

為什麼說Git管理的是修改，而不是檔案呢？我們還是做實驗。第一步，對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命令

然後，再修改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 add-> 第二次修改 ->git commit

你看，我們前面講了，Git管理的是修改，當你用git add命令後，在工作區的第一次修改被放入暫存區，準備提交，但是，在工作區的第二次修改並沒有放入暫存區，所以，git commit只負責把暫存區的修改提交了，也就是第一次的修改被提交了，第二次的修改不會被提交。

提交後，用git diff HEAD -- readme.txt命令可以檢視工作區和版本庫裡面最新版本的區別：

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

那怎麼提交第二次修改呢？你可以繼續git add再git commit，也可以彆著急提交第一次修改，先git add第二次修改，再git commit，就相當於把兩次修改合併後一塊提交了：

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

question：您好,看了這上面說的,如果第一次修改--> git add --> 第二次修改 --> git commit ,那麼第二次修改就會提交不上去,但是我測試了下,第一次修改後add,然後再修改後直接commit,發現檔案裡面第二次修改的東西也在的啊,不是應該提交不上去的麼

ans：git commit 的作用是將 暫存區 的檔案提交到 倉庫 中 並不會改變工作目錄下的檔案，所以你工作目錄修改的東西仍然存在，如果你此時使用 git reset --hard 你會發現你的工作目錄同步成為倉庫的狀態 第二次修改但未add的內容不見了

7.撤銷修改

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

場景2：當你不但改亂了工作區某個檔案的內容，還新增到了暫存區時，想丟棄修改，分兩步，第一步用命令git reset [--mixed] HEAD <file>，就回到了場景1，第二步按場景1操作。

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

自然，你是不會犯錯的。不過現在是凌晨兩點，你正在趕一份工作報告，你在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意思就是，把readme.txt檔案在工作區的修改全部撤銷，這裡有兩種情況：

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

一種是readme.txt已經新增到暫存區後，又作了修改，現在，撤銷修改就回到新增到暫存區後的狀態。

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

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

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>可以將HEAD指向的最新快照回滾至暫存區域。

git reset HEAD <file>的原命令為git reset --mixed HEAD <file>

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

再用git status檢視一下，現在暫存區是乾淨的，工作區有修改：

Q：為什麼暫存區是乾淨的而工作區有修改？

A：因為此時暫存區對應的檔案是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

整個世界終於清靜了！

8.刪除檔案

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

在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

一般情況下，你通常直接在檔案管理器中把沒用的檔案刪了。

這個時候，Git知道你刪除了檔案，因此，工作區和版本庫就不一致了，git status命令會立刻告訴你哪些檔案被刪除了：

現在有兩種情況：

確實要從版本庫中刪除該檔案
誤刪

1. 如果是確實要從版本庫中刪除該檔案，那就用命令git rm刪掉，並且git commit：

2. 誤刪：因為版本庫裡還有呢，所以可以很輕鬆地把誤刪的檔案恢復到最新版本（以下兩條命令都可以）：

$ git checkout -- test.txt

$ git restore test.txt

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

9.github專案上傳與下載

首先需要在GitHub上建立一個空的倉庫(步驟省略)，然後，把本地倉庫的內容推送到GitHub倉庫。

現在，我們根據GitHub的提示，在本地的learngit倉庫下執行命令：

$ git remote add origin https://github.com/tgpcai/learngit.git

新增後，遠端庫的名字就是origin，這是Git預設的叫法，也可以改成別的，但是origin這個名字一看就知道是遠端庫。

下一步，就可以把本地庫的所有內容推送到遠端庫上：

$ git push -u origin master

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

由於遠端庫是空的，我們第一次推送master分支時，加上了-u引數，Git不但會把本地的master分支內容推送的遠端新的master分支，還會把本地的master分支和遠端的master分支關聯起來，在以後的推送或者拉取時就可以簡化命令。

推送成功後，可以立刻在GitHub頁面中看到遠端庫的內容已經和本地一模一樣。

從現在起，只要本地作了提交，就可以通過命令：

$ git push origin master

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

從Github上下載專案到本地，可以通過命令：

$ git clone + 專案地址

10.建立與合併分支

Git鼓勵大量使用分支：

檢視分支：git branch

建立分支：git branch <name>

切換分支：git switch <name>

建立+切換分支：git switch -c <name>

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

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

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

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

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

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

Git建立一個分支很快，因為除了增加一個dev指標，改改HEAD的指向，工作區的檔案都沒有任何變化！

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

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

所以Git合併分支也很快！就改改指標，工作區內容也不變！

合併完分支後，甚至可以刪除dev分支。刪除dev分支就是把dev指標給刪掉，刪掉後，我們就剩下了一條master分支：

下面開始實戰。

首先，我們建立dev分支，然後切換到dev分支：

$ git switch -c dev

然後，用git branch命令檢視當前分支：

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

然後，我們就可以在dev分支上正常提交，比如對readme.txt做個修改，加上一行：

然後提交：

現在，dev分支的工作完成，我們就可以切換回master分支：

$ git switch master

切換回master分支後，再檢視一個readme.txt文件，剛才新增的內容不見了！因為那個提交是在dev分支上，而master分支此刻的提交點並沒有變：

現在，我們把dev分支的工作成果合併到master分支上：

$ git merge dev

git merge命令用於合併指定分支到當前分支。合併後，再檢視readme.txt的內容，就可以看到，和dev分支的最新提交是完全一樣的。

注意到上面的Fast-forward資訊，Git告訴我們，這次合併是“快進模式”，也就是直接把master指向dev的當前提交，所以合併速度非常快。

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

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

$ git branch -d dev

因為建立、合併和刪除分支非常快，所以Git鼓勵你使用分支完成某個任務，合併後再刪掉分支，這和直接在master分支上工作效果是一樣的，但過程更安全。

11.分支管理--解決衝突

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

解決衝突就是把Git合併失敗的檔案手動編輯為我們希望的內容，再提交。

用git log --graph命令可以看到分支合併圖。

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

$ git switch -c feature1
Switched to a new branch 'feature1'

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

Creating a new branch is quick AND simple.

在feature1分支上提交：

切換到master分支：

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也可以告訴我們衝突的檔案：

使用vim命令可以檢視readme.txt的內容

Git用<<<<<<<，=======，>>>>>>>標記出不同分支的內容，我們修改master分支下的readme.txt如下後儲存：

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

最後，刪除feature1分支：

$ git branch -d feature1

12.分支管理策略

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

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

通常，合併分支時，如果可能，Git會用Fast forward模式，但這種模式下，刪除分支後，會丟掉分支資訊。

如果要強制禁用Fast forward模式，Git就會在merge時生成一個新的commit，這樣，從分支歷史上就可以看出分支資訊。

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

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

$ git switch -c 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 switch master
Switched to branch 'master'

準備合併dev分支，請注意--no-ff引數，表示禁用Fast forward：

因為本次合併要建立一個新的commit，所以加上-m引數，把commit描述寫進去。

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

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

12.1分支策略

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

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

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

你和你的小夥伴們每個人都在dev分支上幹活，每個人都有自己的分支，時不時地往dev分支上合併就可以了。

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

13.分支管理之Feature分支

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

如果要丟棄一個沒有被合併過的分支，可以通過git branch -D <name>強行刪除。

14.分支管理之Bug分支

修復bug時，我們會通過建立新的bug分支進行修復，然後合併，最後刪除；

當手頭工作沒有完成時，先把工作現場git stash一下，也可以使用git stash list檢視儲存了多少個工作現場，然後去修復bug，修復後，再git stash pop，回到工作現場；[在git stash命令之前，記得需要把工作現場的所以檔案都先git add一下，否則後面會出錯，具體原因見廖雪峰GIT教程中的評論]

在master分支上修復的bug，想要合併到當前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“複製”到當前分支，避免重複勞動。其中<commit>指修復bug中git commit命令輸出的一串字元。

15.分支管理之多人協作

檢視遠端庫資訊，使用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，如果有衝突，要先處理衝突。

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

要檢視遠端庫的資訊，用git remote：

或者，用git remote -v顯示更詳細的資訊：

上面顯示了可以抓取和推送的origin的地址。如果沒有推送許可權，就看不到push的地址。

15.1 推送分支

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

$ git push origin master

如果要推送其他分支，比如dev，就改成：

$ git push origin dev

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

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

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

15.2 抓取分支

多人協作時，大家都會往master和dev分支上推送各自的修改。

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

當你的小夥伴從遠端庫clone時，預設情況下，你的小夥伴只能看到本地的master分支。不信可以用git branch命令看看：

現在，你的小夥伴要在dev分支上開發，就必須建立遠端origin的dev分支到本地，於是他用這個命令建立本地dev分支：

$ git checkout -b dev origin/dev

現在，他就可以在dev上繼續修改，然後，時不時地把dev分支push到遠端：

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

推送失敗，因為你的小夥伴的最新提交和你試圖推送的提交有衝突，解決辦法也很簡單，Git已經提示我們，先用git pull把最新的提交從origin/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成功，但是合併有衝突，需要手動解決，解決的方法和分支管理中的解決衝突完全一樣。解決後，提交，再push：

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

首先，可以試圖用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>。

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

16.分支管理之變基操作(rebase)

假設你現在基於遠端分支"origin"，建立一個叫"mywork"的分支。

$ git checkout -b mywork origin

現在我們在這個分支做一些修改，然後生成兩個提交(commit).

$ vi file.txt
$ git commit
$ vi otherfile.txt
$ git commit
...

但是與此同時，有些人也在"origin"分支上做了一些修改並且做了提交了. 這就意味著"origin"和"mywork"這兩個分支各自"前進"了，它們之間"分叉"了。

在這裡，你可以用git pull命令把"origin"分支上的修改拉下來並且和你的修改合併；結果看起來就像一個新的"合併的提交"(merge commit):

但是，如果你想讓"mywork"分支歷史看起來像沒有經過任何合併一樣，你也許可以用git rebase:

$ git checkout mywork
$ git rebase origin

這些命令會把你的"mywork"分支裡的每個提交(commit)取消掉，並且把它們臨時儲存為補丁(patch)(這些補丁放到".git/rebase"目錄中),然後把"mywork"分支更新到最新的"origin"分支，最後把儲存的這些補丁應用到"mywork"分支上。

當'mywork'分支更新之後，它會指向這些新建立的提交(commit),而那些老的提交會被丟棄。如果執行垃圾收集命令(pruning garbage collection), 這些被丟棄的提交就會刪除. （請檢視git gc)

現在我們可以看一下用合併(merge)和用rebase所產生的歷史的區別：

在rebase的過程中，也許會出現衝突(conflict). 在這種情況，Git會停止rebase並會讓你去解決衝突；在解決完衝突後，用"git-add"命令去更新這些內容的索引(index), 然後，你無需執行 git-commit,只要執行:

$ git rebase --continue

這樣git會繼續應用(apply)餘下的補丁。

在任何時候，你可以用--abort引數來終止rebase的行動，並且"mywork" 分支會回到rebase開始前的狀態。

$ git rebase --abort

17.標籤管理之建立標籤

命令git tag <tagname>用於新建一個標籤，預設為HEAD，也可以指定一個commit id；
命令git tag -a <tagname> -m "blablabla..."可以指定標籤資訊；
命令git tag可以檢視所有標籤。
命令git show <tagname>可以看到標籤說明文字

18.標籤管理之操作標籤

命令git push origin <tagname>可以推送一個本地標籤；
命令git push origin --tags可以推送全部未推送過的本地標籤；
命令git tag -d <tagname>可以刪除一個本地標籤；
命令git push origin :refs/tags/<tagname>可以刪除一個遠端標籤。