一篇長文說 git 基礎

版本管理在產品級開發中是非常重要的一個部分，它涉及到團隊協作，且影響到產品最終的發佈、上線以及測試環節，當前最流行的版本控制系統是 git。git 內容非常多，本文儘量剋制地來介紹 git 的基礎內容

概述

版本控制系統的作用

版本控制系統(Version Control System)是一種記錄若干文件修訂記錄的系統，它有以下三個作用：

1、從當前版本回退到任意版本

2、查看歷史版本

3、對比兩個版本差異

git 優勢

1、速度快

2、設計簡單

3、輕量級的分支操作，允許上千個並行開發的分支，對非線性開發模式的強力支持

4、有能力高效管理類似 linux 內核一樣的超大規模項目

5、git 已經成為事實上的標準，幾乎所有優秀的前端項目都通過 git 來進行版本控制

6、社區成熟活躍，git 的流行離不開 github 的貢獻

重要概念

要理解 git，首先要了解 git 中的重要概念

【術語介紹】

<code>
repository
 
倉庫
branch
 
分支
summary
 
概要
track 
 
跟蹤
modify
 
修改
stage
 
暫存
commit
 
提交
push
 
推送
pull
 
拉取
clone
 
克隆
amend
 
修改
merge
 
合併
conflict
 
衝突
origin
 
起源
upstream
 
上游
downstream 
 
下游
verbose
 
冗長的
reflog
 
迴流
/<code>

【.git 目錄】

每個項目都有一個 git 目錄(如果 git clone 出來的話，就是其中.git 的目錄)，它是 git 用來保存元數據和對象數據庫的地方。這個目錄非常重要，每次克隆鏡像倉庫的時候，實際拷貝的就是這個目錄裡面的數據

【三種狀態】

對於任何一個文件，在 git 中都只有三種狀態：已提交(committed)，已修改(modified)和已暫存(staged)

<code>已提交：該文件已經被安全地保存在本地數據庫中了
已修改：修改了某個文件，但還沒有提交保存
已暫存：把已修改的文件放在下次提交時要保存的清單中/<code>

文化的三種狀態正好對應文件流轉的三個工作區域：git 的工作目錄，暫存區域，以及本地倉庫

下面來分別解釋下，這三個工作區域

工作目錄是對項目的某個版本獨立提取出來的內容

暫存區域是一個簡單的文件，一般都放在 .git 目錄中。有時候人們會把這個文件叫做索引文件

本地倉庫就是指的 .git 目錄

基本的 git 工作流程如下：

1、在工作目錄中修改某些文件

2、對修改後的文件進行快照，然後保存到暫存區域

3、提交更新，將保存在暫存區域的文件快照永久轉儲到Git目錄中

【commit 哈希值】

在保存到 git 之前，所有數據都要進行內容的校驗和(checksum)計算，並將此結果作為數據的唯一標識和索引，而不是文件名

git 使用 SHA-1 算法計算數據的校驗和，通過對文件的內容或目錄的結構計算出一個SHA-1哈希值，作為指紋字符串。該字符串由40個十六進制字符(0-9及a-f)組成，看起來就像是：

<code>23b9da6552252987aa493b52f8696cd6d3b00372/<code>

git 配置

配置級別

git 共有三個配置級別

<code>　　 

　　 

　　/<code>

基礎配置

一般在新的系統上，需要先配置下自己的 git 工作環境。配置工作只需一次，以後升級時還會沿用現在的配置。當然，如果需要隨時可以用相同的命令修改已有的配置

1、用戶名

<code>git config --
global
 user.name 
"xiaohuochai"
/<code>

2、郵箱

<code>
git
 config --global user.email 
"121631835
@qq
.com"
/<code>

3、文本編輯器

<code>git config --
global
 core.editor 
"code --wait"
/<code> 

4、更改 git 處理行結束條符的方式

Windows 使用回車（CR）和換行（LF）兩個字符來結束一行，而 Mac 和 Linux 只使用換行（LF）一個字符。下面的代碼告訴 git 在提交時把回車和換行轉換成換行，檢出時不轉換。這樣在 Windows 上的檢出文件中會保留回車和換行，而在 Mac 和 Linux 上，以及版本庫中會保留換行

<code>git 
config
 /<code>

5、取消對中文的轉義

使用 git 時，經常會碰到有一些中文文件名或者路徑被轉義成\xx\xx\xx的情況，通過下面的配置可以改變默認轉義

<code>git config --
global
 core.quotepath 
false
/<code>

6、只允許 push 當前分支到遠程同名分支上

<code>git config --
global
 push.
default
 simple/<code>

查看配置

<code>git config --
list
  
git config -- 
list
 --
global
  
git config user.name /<code>

如果要刪除或修改配置，更簡單的辦法是直接打開~/.gitconfig文件，或者.git/config文件修改即可

關於忽略的配置

一般總會有些文件無需納入 git 的管理，也不希望它們總出現在未跟蹤文件列表

可以在項目根目錄創建一個名為 .gitignore 的文件，列出要忽略的文件模式

文件 .gitignore 的格式規範如下：

1、所有空行或者以註釋符號 ＃ 開頭的行都會被 git 忽略

2、可以使用標準的glob模式匹配

3、匹配模式以反斜槓(/)開頭防止遞歸

4、匹配模式最後跟反斜槓(/)說明要忽略的是目錄

5、要忽略指定模式以外的文件或目錄，可以在模式前加上歎號(!)取反

.gitignore 文件常見設置如下

<code>node_modules/
ecosystem.json
.DS_Store
.idea
.vscode/<code>

SSH 配置

如果要進行遠程操作，即從 github 遠程服務器 push 和 pull 代碼，需要解決一個問題，就是 github 怎麼知道是我在提交我的代碼？
除了每次輸入用戶名、密碼外，更簡單的方式是配置 SSH

大多數 git 服務器都會選擇使用 SSH 公鑰來進行授權。系統中的每個用戶都必須提供一個公鑰用於授權

首先先確認一下是否已經有一個公鑰了。SSH公鑰默認儲存在賬戶的主目錄下的 ~/.ssh 目錄，有.pub後綴的文件就是公鑰，另一個文件則是密鑰

然後，使用如下命令來生成 SSH key，然後一路回車，使用默認值即可

<code>$ ssh-keygen -t rsa -b 
4096
 -C 
121631835
@qq.com/<code>

如果一切順利的話，可以在用戶主目錄裡找到 .ssh 目錄，裡面有 id_rsa 和 id_rsa.pub 兩個文件，這兩個就是 SSH Key 的秘鑰對，id_rsa 是私鑰，不能洩露出去，id_rsa.pub 是公鑰，可以放心地告訴任何人

SSH的公鑰如下所示：

<code>$ cat ~
/.ssh/id 
_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC3ltgCdqTIrPuN6yMYCeSMg8shtM+TRBIULDmfeh/
9
lE51e2g2t8ytLxz/QrPu3jvvpBqMimyPxC0NyW38eIHP9dkXTS0V76LlXy1MZvIjP3SnaU3AJs/fke61wc9y9EdPfrpSjIZpG7Z134+huaioLhPRShRmUQjl3plC9a89fnCyzTmtix5fDKKFjU3ZU6uVSDPy8+o+vsTfwAPQ1ylaBbY733Y1shmd6Texwmb8ttkv1Xj31RdhTdSS2eI3pSN/Ld1GC6/d2u3zcLnC6T4+
1
WLd0KTm/lqdzB2uWSsnMBI11wfKdw3pqEI17oGrPxurmunoMPzyR/dHwkfwotwh 
121631835
@qq.com/<code>

接下來，登陸 gitHub，打開 Settings 中的 SSH Keys 頁面

然後，點 New SSH Key，填上任意 Title，在 Key 文本框裡粘貼 id_rsa.pub 文件的內容

點擊 Add SSH key 按鈕後，即算配置完成了

接下來，使用 ssh -T [email protected] 來測試 SSH 是否配置成功

<code>$ ssh -T [email protected]
Hi littlematch0123! You
've successfully authenticated, but GitHub does not provide shell access.
/<code>

回到這部分最開始的問題，在請求代碼時，我怎麼知道對方是 github 呢？也需要 github 提供一個公鑰給我，所以在第一次連接 github 時要選擇 yes 來接受對方的公鑰，也就是下面的代碼

<code>  
ssh -T [email protected]
The
 
authenticity of host 'github.com (13.250.177.223)' can't be established.
RSA
 
key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are
 
you sure you want to continue connecting (yes/no)? yes
warning
: 
Permanently added 'github.com' (rsa) to the list of known hosts
Hi
 
littlematch0123! You've successfully authenticated, but GitHub does not provide shell access.
/<code>

git 基礎操作

初始化新倉庫

要對現有的某個項目開始用 git 管理，只需到此項目所在的目錄，執行

<code>$ git 
init
/<code> 

初始化後，在當前目錄下會出現一個名為 .git 的目錄，所有 git 需要的數據和資源都存放在這個目錄中。不過目前，僅僅是按照既有的結構框架初始化好了裡邊所有的文件和目錄，但還沒有開始跟蹤管理項目中的任何一個文件

檢查文件狀態

要確定哪些文件當前處於什麼狀態，可以用 git status 命令

如果在取得倉庫之後立即執行此命令，會看到類似這樣的輸出

<code>$ git status
On branch master
Initial 
commit
nothing
 
to
 
commit
(
create
/copy files 
and
 
use
 
"git add"
 
to
 track)/<code>

這說明現在的工作目錄相當乾淨。換句話說，所有已跟蹤文件在上次提交後都未被更改過，或者沒有任何文件

現在創建一個新文件README，保存退出後運行 git status 會看到該文件出現在未跟蹤文件列表中

<code>$ git status
On branch master

No commits yet

Untracked files:
  (
use
 
"git add ..."
 
to
 
include
 
in
 what will be committed)

    README.txt

nothing
 added 
to
 
commit
 but untracked files 
present
 (
use
 
"git add"
 
to
 track)/<code>

在狀態報告中可以看到新建的README文件出現在“Untracked files”下面。未跟蹤的文件意味著 git 在之前的快照(提交)中沒有這些文件

跟蹤新文件

使用命令 git add 開始跟蹤一個新文件。所以，要跟蹤README文件，運行

<code>$ git 
add
 README.txt/<code>

使用命令 git add . 會批量跟蹤所有工作目錄下未被跟蹤的文件

<code>$ git 
add
 ./<code>

此時再運行 git status 命令，會看到README文件已被跟蹤，並處於暫存狀態

<code>$ git status
On branch master

No commits yet

Changes to be committed:
  (
use
 
"git rm --cached ..."
 
to
 unstage)

    
new
 
file
:   README.txt/<code>

只要在“Changes to be committed”這行下面的，就說明是已暫存狀態

暫存已修改文件

現在修改下之前已跟蹤過的文件README.txt，將其內容修改為hello world

然後再次運行status命令，會看到這樣的狀態報告：

<code>$ echo hello world > README.txt
$ git status
On branch master

No commits yet

Changes to be committed:
  (
use
 
"git rm --cached ..."
 to unstage)

    new file:   README.txt

Changes 
not
 staged 
for
 commit:
  (
use
 
"git add ..."
 to update what will be committed)
  (
use 
 
"git checkout -- ..."
 to discard changes in working directory)

    modified:   README.txt/<code>

文件README.txt出現在 “Changes not staged for commit” 這行下面，說明已跟蹤文件的內容發生了變化，但還沒有放到暫存區。要暫存這次更新，需要運行git add命令

git add 命令是個多功能命令，根據目標文件的狀態不同，此命令的效果也不同：可以用它開始跟蹤新文件，或者把已跟蹤的文件放到暫存區，還能用於合併時把有衝突的文件標記為已解決狀態等

因此，將這個命令理解為“添加內容到下一次提交中”而不是“將一個文件添加到項目中”要更加合適

現在運行 git add 將README.txt放到暫存區，然後再看看git status的輸出

<code>$ git status
On branch master

No commits yet

Changes to be committed:
  (
use
 
"git rm --cached ..."
 
to
 unstage)

    
new
 
file
:   README.txt/<code>

提交更新

每次準備提交前，先用 git status 看下，是不是都已暫存起來了，然後再運行提交命令git commit

<code>$ git commit/<code>

這種方式會啟動文本編輯器以便輸入本次提交的說明，編輯器會顯示類似下面的文本信息

<code>
 
 
 
 
 
 
 
 
 
 
 
 
/<code>

可以看到，默認的提交消息包含最後一次運行 git status 的輸出，放在註釋行裡，另外開頭還有一空行，需要輸入提交說明

另外也可以用 -m 參數後跟提交說明的方式，在一行命令中提交更新

<code>$ git 
commit
 -m 
'更新 README 內容'
[
master
 
34
c5aa0] 更新 README 內容
 
1
 
file
 
changed
, 
1
 insertion(+), 
1
 deletion(-)/<code>

提交後它會提示，當前是在哪個分支(master)提交的，本次提交的完整SHA-1校驗和是什麼(34c5aa0)，以及在本次提交中，有多少文件修訂過，多少行添改和刪改過

在提交的時候，給 git commit 加上 -a 選項，git 會自動把所有已經跟蹤過的文件暫存起來一併提交

<code>$ git 
commit
 -am 
'更新 README'
[
master
 daa40d0] 更新 README
 
1
 
file
 
changed
, 
1
 insertion(+), 
1
 deletion(-)/<code>

但是，跳過 git add 步驟，不等於完全不使用 git add。因為 git commit -a 是將所有跟蹤過的文件暫存起來並提交，只是省略了暫存這一步。但一個未跟蹤狀態的文件需要使用 git add 命令來使其變成已跟蹤狀態

還有一種提交方式是使用 -v 或--verbose選項，翻譯成中文是冗餘的，它不僅能回顧剛剛修改的內容，而且會迫使把提交理由寫得更詳細些

<code>將 README 內容中的 12345 去掉
 
 
 
 
 
 
 
 
 
 
diff  
index 5c1d8ad..95d09f2 100644
 
+++ b/README.txt
@@ -1 +1 @@
-hello world12345
\ No newline at 
end
 
of
 
file
+hello world
\ 
No 
 
newline
 
at
 
end
 
of
 
file
/<code>

輸出結果如下：

<code>$ git 
commit
  
[
master
 
2494
a62] 將 README 內容中的 
12345
 去掉
 
1
 
file
 
changed
, 
1
 insertion(+), 
1
 deletion(-)/<code>

git 查看

狀態簡覽

git status 命令的輸出十分詳細，但其用語有些繁瑣。 如果使用 git status -s 命令或 git status --short 命令，將得到一種更為緊湊的格式輸出

<code>$ git status -s
 M README    
MM Rakefile  
A  lib/git.rb  
M  lib/simplegit.rb  
?? LICENSE.txt /<code>

一般地，-s 選項與-b選項同時使用，s 代表 summary(概要)，b 代表 branch(分支)

<code>$ git status -sb
 
 M 
"git.md"
/<code>

狀態詳覽

如果在知道具體哪行發生了改變，要使用 git diff 命令

git diff 命令比較的是工作目錄中當前文件和暫存區域快照之間的差異， 也就是修改之後還沒有暫存起來的變化內容，如果暫存了所有更新過的文件後，則運行 git diff 後會什麼都沒有

下面的代碼中，README.txt 文件的內容從 'hello world1' 變化到 'hello world123'

<code>$ git diff
diff  
index 62b372b..6d7f756 100644
 
+++ b/README.txt
@@ -1 +1 @@
-hello world1
\ No newline at 
end
 
of
 
file
+hello world123
\ 
No
 
newline
 
at
 
end
 
of
 
file
/<code>

如果要看已經暫存起來的文件和上次提交時的快照之間的差異，可以用 git diff--cached 命令

下面的代碼中，README.txt 文件的內容從空內容變化到 'hello world1'

<code>$ git diff  
diff  
new file mode 100644
index 0000000..62b372b
 
+++ b/README.txt
@@ -0,0 +1 @@
+hello world1
\ No newline at 
end
 
of
 
file
/<code>

查看提交歷史

使用 git log 命令可以查看提交歷史

<code>$ git log
commit
 
3
f7b9ed403e6d624651014a5d15c481463572c15 (
HEAD
 -> 
master
)
Author: xiaohuochai <
121631835
@qq.com>
Date
:   Sun 
Dec
 
29
 
23
:
19
:
44
 
2019
 +
0800

    
add
 b

commit
 ee5ae6f1dd5f620f4d2ac4a3702eb4814a062fce
Author: xiaohuochai <
121631835
@qq.com>
Date 
:   Sun 
Dec
 
29
 
23
:
15
:
10
 
2019
 +
0800

    
delete
 c/<code>

默認不用任何參數的話，git log 會按提交時間列出所有的更新，最近的更新排在最上面，每次更新都有一個SHA-1校驗和、作者的名字和電子郵件地址、提交時間，最後縮進一個段落顯示提交說明

我們常用 -p 選項展開顯示每次提交的內容差異，用 -2 則僅顯示最近的兩次更新

<code>$ git log -p -2
commit
 
3
f7b9ed403e6d624651014a5d15c481463572c15 (
HEAD
 -> 
master
)
Author: xiaohuochai <
121631835
@qq.com>
Date
:   Sun 
Dec
 
29 
 
23
:
19
:
44
 
2019
 +
0800

    
add
 b

diff  
new
 
file
 
mode
 
100644
index
 
0000000.
.e69de29

commit
 ee5ae6f1dd5f620f4d2ac4a3702eb4814a062fce
Author: xiaohuochai <
121631835
@qq.com>
Date
:   Sun 
Dec
 
29
 
23
:
15
:
10
 
2019
 +
0800

    
delete
 c

diff  
deleted 
file
  
mode
 
100644
index
 e69de29.
.0000000
/<code>

該選項除了顯示基本信息之外，還在附帶了每次 commit 的變化。當進行代碼審查，或者快速瀏覽某個搭檔提交的 commit 的變化時，這個參數就非常有用了

可以用 --oneline 選項將每個提交放在一行顯示，這在提交數很大時非常有用

<code>$ git 
log
 --oneline
3f
7b9ed (HEAD -> master) add b
ee5ae6f 
delete
 c/<code>

git 命令歷史

git reflog 命令按照之前經過的所有的 commit 路徑按序來排列，用來記錄每一次命令，常用於版本切換的輔助操作中

<code>$ git reflog/<code>

git 版本切換

git 要進行版本切換，就必須知道當前版本是哪個版本。在 git 中，用 HEAD 來表示當前版本，也就是最新的提交，上一個版本就是 HEAD^，上上一個版本就是 HEAD^^，當然往上100個版本寫100個^比較容易數不過來，所以寫成 HEAD~100

先使用 git log --online 來簡覽當前的提交歷史

<code>  
git log --oneline
e7422c8
 
(HEAD -> master) add b
ee5ae6f
 
delete c
8760a0f
 
add c
/<code>

使用命令 git reset --hard commit_id 在版本的歷史之間切換

<code> git 
reset
  
HEAD
 
is
 
now
 
at
 ee5ae6f 
delete
 c/<code>

再使用 git log --online 來簡覽提交歷史，發現最新的那個版本已經看不到了

<code>$ git 
log
 --
oneline
ee5ae6f
 
(HEAD -> master)
  
delete
 c
8760a0f add c
/<code>

如果找到最新版本的提交對象呢？ git提供了一個命令 git reflog，該命令按照之前經過的所有的 commit 路徑按序來排列，用來記錄每一次命令

<code>$ git reflog
ee5ae6f (HEAD -> master) HEAD@{0}: 
reset
: moving to HEAD^
e7422c8 HEAD@{1}: commit (amend): add b
3
f7b9ed HEAD@{2}: commit: add b
ee5ae6f (HEAD -> master) HEAD@{3}: commit: 
delete
 c
8760
a0f HEAD@{4}: commit: add c/<code>

從 git reflog 命令返回的結果中發現，e7422c8 是最新版本的 commit id

　　下面使用 git reset --hard 命令，將文件恢復到最新版本

<code>$ git 
reset
  
HEAD
 
is
 
now
 
at
 e7422c8 
add
 b/<code>

git 分支管理

幾乎每一種版本控制系統都以某種形式支持分支。使用分支意味著可以從開發主線上分離開來，然後在不影響主線的同時繼續工作。

git 中的分支，其實本質上僅僅是個指向 commit 對象的可變指針，即一個包含所指對象校驗和(40個字符長度SHA-1字串)的文件，所以創建和銷燬一個分支就變得非常廉價。說白了，新建一個分支就是向一個文件寫入41個字節(外加一個換行符)那麼簡單，當然也就很快了

git 會使用 master 作為分支的默認名字。在若干次提交後，其實已經有了一個指向最後一次提交對象的 master 分支，它在每次提交的時候都會自動向前移動

創建分支

創建一個新的分支指針。比如新建一個 testing 分支，可以使用 git branch 命令

<code>$ git branch testing/<code>

這會在當前 commit 對象上新建一個分支指針

git 保存著一個名為 HEAD 的特別指針，它是一個指向正在工作中的本地分支的指針(可以將 HEAD 想象為當前分支的別名)。運行 git branch 命令，僅僅是建立了一個新的分支，但不會自動切換到這個分支中去，所以在這個例子中，依然還在 master 分支裡工作

切換分支

要切換到其他分支，可以執行 git checkout 命令。現在轉換到新建的 testing 分支，這樣 HEAD 就指向了 testing 分支

<code>$ git checkout testing/<code>

git checkout 使用 -b選項，可以新建並切換到該分支，比如 iss53 分支

<code>$ git checkout -b iss53/<code>

合併分支

可以使用 git merge 命令來實現分支合併。一般地，合併分支有以下三種情況

1、快進(Fast forward)合併

如果當前 master 分支所在的提交對象是要併入的 hotfix 分支的直接上游，git 只需把 master 分支指針直接右移。換句話說，如果順著一個分支走下去可以到達另一個分支的話，那麼 git 在合併兩者時，只會簡單地把指針右移，因為這種單線的歷史分支不存在任何需要解決的分歧，所以這種合併過程可以稱為快進(Fast forward)

<code>$ git checkout master
$ git 
merge
 hotfix
Updating f42c576.
.3
a0874c
Fast
-forward
 README | 
1
 -
 
1
 
file
 
changed
, 
1
 deletion(-)/<code>

2、無衝突合併

如下圖所示，issue 53分支要合併回 master 分支中，git 會用兩個分支的末端(C4和C5)以及它們的共同祖先(C2)進行一次簡單的三方合併計

<code>$ git checkout master
$ git 
merge
 iss53
Auto
-merging README
Merge
 made 
by
 the 
'recursive'
 strategy.
 README | 
1
 +
 
1
 
file
 
changed
, 
1
 insertion(+)/<code>

git 對三方合併後的結果重新做一個新的快照，並自動創建一個指向它的提交對象(C6)。這個提交對象比較特殊，它有兩個祖先(C4和C5)

3、有衝突合併

如果在不同的分支中都修改了同一個文件的同一部分，git 就無法乾淨地把兩者合到一起(邏輯上說，這種問題只能由人來裁決)。如果在解決問題 #53 的過程中修改了 hotfix 中修改的部分，將得到類似下面的結果

<code>$ git 
merge
 iss53
Auto
-merging index.html
CONFLICT (
content
): 
Merge
 conflict 
in
 index.html
Automatic
 
merge
 
failed
; fix conflicts and then 
commit
 the result./<code>

git 作了合併，但沒有提交，它會停下來等待解決衝突。要看看哪些文件在合併時發生衝突，可以用 git status 查閱

<code>$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git 
commit
")

Unmerged paths:
  (use "
git 
add
 <
file 
>...
" to mark resolution)

        both modified:      index.html

no changes added to commit (use "
git 
add
" and/or "
git 
commit
 -a
")
/<code>

任何包含未解決衝突的文件都會以未合併(unmerged)的狀態列出。git會在有衝突的文件里加入標準的衝突解決標記，可以通過它們來手工定位並解決這些衝突。可以看到此文件包含類似下面這樣的部分：

<code>
<<
HEAD
<
div
 
id
=
"footer"
>
contact : [email protected]
div
>

=======
<
div
 
id
=
"footer"
>

  please contact us at [email protected]
 
div
>

>>>>>>> iss53
/<code>

在解決了所有文件裡的所有衝突後，要運行 git add 命令將把它們標記為已解決狀態(實際上就是將一次快照保存到暫存區域)。因為一旦暫存，就表示衝突已經解決

再運行一次 git status 來確認所有衝突都已解決

<code>  
git status
On
 
branch master
Changes
 
to be committed:
    
"git reset HEAD ..." to unstage)

        
modified
:   
index.html
/<code>

如果確認所有衝突都已解決，可以用 git commit 來完成這次合併提交。提交說明會自動生成

<code>
Merge
 branch 
'iss53'

Conflicts:
  index.html
 
 
 
 
 
/<code>

查看分支

git branch 命令如果不加任何參數，它會給出當前所有分支的清單。master 分支前的 * 字符表示當前所在的分支。也就是說，如果現在提交更新，master 分支將隨著開發進度前移

<code>$ git branch
  iss53
* 
master
  testing/<code>

若要查看各個分支最後一個提交對象的信息，運行 git branch -v

<code>$ git branch -v
  iss53   
93b
412c fix javascript issue
* master  
7
a98805 Merge branch 
'iss53'
  testing 
782f
d34 
add
 scott to the author list 
in
 the readmes/<code>

刪除分支

之前的工作成果已經合併到 master 了，那麼 iss53 分支也就沒用了。可以使用 git branch -d 命令來刪除它

<code>$ git branch -d iss53/<code>

如果一個分支沒有被合併過，則該分支需要使用 -D 選項來刪除

<code>$ git branch -D iss53/<code>

git 遠程倉庫與分支

要參與任何一個 git 項目的協作，必須要了解該如何管理遠程倉庫。遠程倉庫是指託管在網絡上的項目倉庫，同他人協作開發某個項目時，需要管理這些遠程倉庫，以便推送或拉取數據，分享各自的工作進展。管理遠程倉庫的工作，包括添加遠程庫，移除遠程庫，管理遠程庫分支，定義是否跟蹤這些分支等

遠程分支(remote branch)是對遠程倉庫中的分支的索引。它們是一些無法移動的本地分支；只有在 git 進行網絡交互時才會更新。遠程分支就像是書籤，提醒著上次連接遠程倉庫時上面各分支的位置

通常用(遠程倉庫名)/(分支名)這樣的形式表示遠程分支，比如 origin/master 分支

克隆遠程倉庫

克隆倉庫的命令格式為 git clone [url]。比如，要克隆代碼倉庫 git_learn，可以用下面的命令：

<code>$ git clone git@github.
com:
littlematch0123/git_learn.git/<code>

這會在當前目錄下創建一個名為 git_learn 的目錄，其中包含一個.git的目錄，用於保存下載下來的所有版本記錄，然後從中取出最新版本的文件拷貝。如果進入這個新建的 git_learn 目錄，會看到項目中的所有文件已經在裡邊了，準備好後續開發和使用。如果希望在克隆的時候，自己定義要新建的項目目錄名稱，可以在上面的命令末尾指定新的名字

<code>$ git clone git@github.
com:
littlematch0123/git_learn.git learnGit/<code>

如果最後一個字符是點，表示會在當前目錄存放項目的所有文件，但當前目錄一開始最好是個空目錄

<code>$ git clone git@github.
com:
littlematch0123/git_learn.git ./<code>

查看遠程倉庫

要查看當前配置有哪些遠程倉庫，可以用 git remote 命令，它會列出每個遠程庫的簡短名字。在克隆完某個項目後，至少可以看到一個名為 origin 的遠程庫，git 默認使用這個名字來標識所克隆的原始倉庫

<code>$ git remote
origin/<code>

也可以加上 -v 選項(v為--verbose的簡寫，中文意思是冗長的)，顯示對應的克隆地址。如果沒有推送權限，將看不到 push 的地址

<code>$ git remote -v
origin  [email protected]:littlematch0123/git_learn.git (fetch)
origin  [email protected]:littlematch0123/git_learn.git (
push
)/<code>

添加遠程倉庫

通常情況下，一個本地 git 倉庫對應一個遠程倉庫；然而，在一些情況下，一個本地倉庫需要同時關聯多個遠程倉庫，比如同時將一個項目發佈在 github 和 coding上

添加一個新的遠程倉庫，可以指定一個名字，以便將來引用，運行 git remote add [shortname] [url]

<code>$ git remote add coding [email protected]:ehuo0123/git_learn.git
$ git remote -v
coding  [email protected]:ehuo0123/git_learn.git (fetch)
coding  [email protected]:ehuo0123/git_learn.git (
push
)
origin  [email protected]:littlematch0123/git_learn.git (fetch)
origin  [email protected]:littlematch0123/git_learn.git (
push 
)/<code>

推送本地分支

git push 命令用於將本地分支的更新，推送到遠程主機

<code>$ git push 
<
遠程主機名
>
 
<
本地分支名
>
:
<
遠程分支名
>
/<code>

下面命令的意思是取出我在本地的 serverfix 分支，推送到遠程倉庫的 serverfix 分支中去

<code>$ git 
push
 origin serverfix:serverfix/<code>

當然，分支名字可以不同，但不建議這樣做

<code>
git
 
push
 
origin
 
serverfix
:awesomebranch 
/<code>

因為本地和遠程分支的名字相同，有下面簡要寫法

<code>$ git 
push
 origin serverfix/<code>

如果要把本地的 master 分支推送到 origin 服務器上，可以運行下面的命令

<code>$ git 
push
 origin master/<code>

下面命令表示將當前分支推送到 origin 主機的對應分支，如果當前分支是 master 分支則推送 master 分支，如果是 x 分支則推送 x 分支

<code>$ git 
push
 origin/<code>

一般地，當前分支只有一個追蹤分支，那麼主機名都可以省略

<code>$ git 
push
/<code>

如果當前分支與多個主機存在追蹤關係，則可以使用 -u 選項指定一個默認主機，這樣後面就可以不加任何參數使用 git push

<code>$ git 
push
 -u origin master/<code>

不管是否存在對應的遠程分支，將本地的所有分支都推送到遠程主機，這時需要使用 –all 選項

<code>$ git push /<code>

從服務器抓取數據

使用 git fetch 命令從服務器抓取所有分支的數據

<code>
$
 
git
 
fetch
 
origin
remote: Enumerating objects:
 
4
,
 
done.
remote: Counting objects:
 
100
%
 
(4/4),
 
done.
remote: Compressing objects:
 
100
%
 
(2/2),
 
done.
remote:
 
Total
  
3
 
(delta
 
0
),
 
reused
 
3
 
(delta
 
0
),
 
pack-reused
 
0
Unpacking objects:
 
100
%
 
(3/3),
 
done.
From
 
https://github.com/littlematch0123/git_learn
 
*
 
[new
 
branch]
      
y
          
->
 
origin/y
/<code>

如果加上分支名，則只更新該分支的數據

<code>$ git fetch origin master/<code>

但是要注意的是，fetch 命令只抓取數據，本地不會自動生成一份可編輯的副本（拷貝）。 換句話說，這種情況下，不會有一個新的 y 分支——只有一個不可以修改的 origin/y 指針

可以運行 git merge origin/y 將這些工作合併到當前所在的 master 分支

<code>$ git merge origin/y/<code>

如果想要在自己的 y 分支上工作，可以將其建立在遠程跟蹤分支之上：

<code>$ git checkout -b y origin/y/<code>

從一個遠程跟蹤分支檢出一個本地分支會自動創建所謂的“跟蹤分支”（它跟蹤的分支叫做“上游分支”）。 跟蹤分支是與遠程分支有直接關係的本地分支，本地分支與遠程分支之間建立了一種追蹤關係(tracking)

當克隆一個倉庫時，它通常會自動地創建一個跟蹤 origin/master 的 master 分支

如果在一個跟蹤分支上輸入 git pull，git 能自動地識別去哪個服務器上抓取、合併到哪個分支。所以，實際上，git pull 是 git fetch 後跟git merge FETCH_HEAD 的縮寫。

<code>$ git pull 
< 
遠程主機名
>
 
<
遠程分支名
>
:
<
本地分支名
>
/<code>

比如，要取回 origin 主機的 next 分支，與本地的 master 分支合併，需要寫成下面這樣

<code>$ git pull origin 
next
:master/<code>

如果遠程分支(next)要與當前分支合併，如下

<code>$ git pull origin 
next
/<code>

如果當前分支與遠程分支存在追蹤關係，git pull就可以省略遠程分支名

<code>$ git pull origin/<code>

如果當前分支只有一個追蹤分支，連遠程主機名都可以省略

<code>$ git pull/<code>

如果 git pull 時，提示 no tracking information，則說明本地分支和遠程分支的追蹤關係沒有創建，用命令 git branch --set-upstream branch-name origin/branch-name 來建立追蹤

刪除遠程分支

如果省略本地分支名，則表示刪除指定的遠程分支，因為這等同於推送一個空的本地分支到遠程分支

下面命令表示刪除 origin 主機的 x 分支

<code>$ git 
push
 origin :
x
 
$ git 
push
 origin --
delete
 
x
/<code>

遠程倉庫刪除和重命名

<code>
 git remote rename coding 
cd
 
/<code>

<code>$ git remote rm coding /<code>

不區分遠程倉庫

由於添加了多個遠程倉庫，在 push 和 pull 時便面臨了倉庫的選擇問題。誠然如此較為嚴謹，但是在許多情況下，只需要保持遠程倉庫完全一致，而不需要進行區分，因而這樣的區分便顯得有些“多餘”

先查看當前的 git remote 情況

<code>$ git remote -v
origin  [email protected]:littlematch0123/git_learn.git (fetch)
origin  [email protected]:littlematch0123/git_learn.git (
push
)/<code>

接下來，不額外添加遠程倉庫，而是給現有的遠程倉庫添加額外的URL

使用 git remote set-url --add ，給已有的遠程倉庫添加一個遠程地址

<code>$ git remote 
set
-
url
 /<code>

再次查看所關聯的遠程倉庫：

<code>$ git remote -v
origin  [email protected]:littlematch0123/git_learn.git (fetch)
origin  [email protected]:littlematch0123/git_learn.git (
push
)
origin  [email protected]:ehuo0123/git_learn.git (
push
)/<code>

這樣設置後的 push 和pull 操作與最初的操作完全一致，不需要進行調整

如果不再需要多個倉庫，可以使用git remote set-url --delete ，將其刪除

<code>$ git remote 
set
-
url
 /<code>

git 其他操作

刪除文件

1、從工作目錄中刪除文件，直接使用 rm 命令刪除即可，因為其沒有納入 git 版本庫中，git 並不知道

<code>
touch
 a  
rm a /<code>

如果畫蛇添足地使用 git rm a，反而會提示錯誤

<code>$ git rm a
fatal: pathspec 
'a'
 did 
not
 
match
 any files/<code>

2、從暫存區中刪除文件，需要使用 git rm -f 命令來強制刪除

<code>touch b  
git 
add
 b  
git rm -f b /<code>

如果使用 git rm b，會提示如下錯誤

<code>$ git rm b
error
: the following file has changes staged 
in
 the index:
    b
(use /<code>

3、從本地倉庫中刪除文件，使用git rm命令即可

<code>touch 
c
 # 新建 
c
git add 
c
 # 將 
c
 添加到暫存區
git commit -m 'add 
c
' # 提交到本地倉庫
git rm  
c
 # 刪除 
c
/<code>

4、如果僅僅是想把文件從 git 倉庫中刪除(亦即從暫存區域移除)，但仍然希望保留在當前工作目錄中。換句話說，僅是從跟蹤清單中刪除。比如一些文件不小心納入倉庫後，要移除跟蹤但不刪除文件，以便稍後在 .gitignore 文件中補上，用--cached選項即可

<code>$ git rm d /<code>

文件重命名

1、從工作目錄中文件重命名，直接使用 mv 命令刪除即可，因為其沒有納入 git 版本庫中，git 並不知道

<code>
touch
 a  
mv a a1 /<code>

如果畫蛇添足地使用 git mv a a1，反而會提示錯誤

<code>$ git mv a a1
fatal: not under version control, 
source
=a, destination=a1/<code>

2、從暫存區，或者本地倉庫中重命名文件，直接使用 git mv 命令就可以了

<code>  
git mv b1 b2
localhost
:
t bailiang$ git status 

On
 
branch master
Changes
 
to be committed:
    
"git reset HEAD ..." to unstage)

    
renamed
:    
b1 -> b2
/<code>

撤消操作

任何時候，都有可能需要撤消剛才所做的某些操作。但要注意的是，有些撤銷操作是不可逆的，所以要謹慎小心，一旦失誤，就有可能丟失部分工作成果

1、修改最後一次提交

有時候提交完了才發現漏掉了幾個文件沒有加，或者提交信息寫錯了。想要撤消剛才的提交操作，可以使用 --amend 選項重新提交：

<code>$ git 
commit
 /<code>

如果剛才提交時忘了暫存某些修改，可以先補上暫存操作，然後再運行 --amend 提交

<code>$ git 
commit
 -m 
'initial commit' 

$ git 
add
 forgotten_file
$ git 
commit
 /<code>

上面的三條命令最終只是產生一個提交，第二個提交命令修正了第一個的提交內容

2、取消已暫存的文件
使用 git reset HEAD ... 命令可以取消暫存，將暫存區的文件恢復到工作目錄中

<code>$ git 
reset
 
HEAD
 a.txt/<code>

3、取消對文件的修改

使用 git checkout -- ... 命令可以將文件恢復到上一個版本的狀態。要注意的是這個命令非常危險，對文件做的任何修改都會消失，因為只是拷貝了另一個文件來覆蓋它。除非確實不想要那個文件了，否則不要使用這個命令

<code>$ git checkout /<code>

注意事項

1、版本控制系統只能跟蹤文本文件的改動，比如TXT文件，網頁，所有的程序代碼等等。圖片、視頻這些二進制文件，雖然也能由版本控制系統管理，但沒法跟蹤文件的變化，只能把二進制文件每次改動串起來，也就是隻知道圖片從100KB改成了120KB，但到底改了啥，版本控制系統不知道，也沒法知道

微軟的 Word 格式是二進制格式，因此，版本控制系統是沒法跟蹤 Word

當然，辦法也是有的，需要安裝 docx2txt 程序，將 word 文檔轉換為可讀的文本文件

把下面這行文本加到 .gitattributes 文件中：

<code>*.docx diff=word/<code>

寫一個腳本把輸出結果包裝成 git 支持的格式。 在可執行路徑下創建一個叫 docx2txt 文件，添加這些內容：

<code> 
docx2txt.pl 
$1
 -/<code>

用 chmod a+x 給這個文件加上可執行權限。 最後，需要配置 git 來使用這個腳本

<code>$ git 
config
 diff.word.textconv docx2txt/<code>

現在如果在兩個快照之間進行比較，git 就會對那些以 .docx 結尾的文件應用“word”過濾器，即 docx2txt。這樣，Word 文件就能被高效地轉換成文本文件並進行比較了

2、不要使用 Windows 自帶的記事本編輯任何文本文件。原因是 Microsoft 開發記事本的團隊使用了一個非常弱智的行為來保存UTF-8編碼的文件，他們自作聰明地在每個文件開頭添加了0xefbbbf(十六進制)的字符，會遇到很多不可思議的問題

3、git commit -am可以寫成git commit -a -m，但不能寫成git commit -m -a

4、在 git 中任何已提交的東西幾乎總是可以恢復的，但任何未提交的東西丟失後很可能再也找不到了

常用命令

基礎操作

<code>$ git init   
$ git add   
$ git add .   
$ git rm   
$ git rm -f   
$ git rm --cached   
$ git commit   
$ git commit -m 
'wrote a file'
   
$ git commit -am 
'wrote a file'
   
$ git commit -v  
$ git commit --amend   
$ git reset HEAD    
$ git checkout --   /<code>

查看操作

<code>
 git status  
 git status -s 
 git diff  
 git diff --cached  
 git diff id1 id2  
 git 
log
  

 git 
log
 -p 

 git 
log
 -2 

 git 
log
 --oneline 

 
 git 
log
 --all 

 git 
log
 --graph  

 git reflog  
/<code>

分支操作

<code>$ git branch   
$ git branch -v   
$ git branch    
$ git branch -d    
$ git branch -D    
$ git checkout     
$ git checkout -b    
$ git checkout -   
$ git merge    
$ git reset --hard   /<code>

遠程操作

<code>
 git remote   
 git remote -v  
 git remote add [shortname] [url]  
 git remote rename pb paul   
 git remote rm [shortname]   
 git remote 
set
-url --add    

 git remote 
set
-url --delete    

 git 
clone
   

 git push origin   
 git fetch origin  
 git pull origin   
 git push origin :serverfix  
 git push origin --delete serverfix  
/<code>