1. 程式人生 > >一篇長文說 git 基礎

一篇長文說 git 基礎

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

概述

版本控制系統的作用

版本控制系統(Version Control System)是一種記錄若干檔案修訂記錄的系統,它有以下三個作用:

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

2、檢視歷史版本

3、對比兩個版本差異

git 優勢

1、速度快

2、設計簡單

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

4、有能力高效管理類似 linux 核心一樣的超大規模專案

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

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

重要概念

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

【術語介紹】

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

.git

目錄】

每個專案都有一個 git 目錄(如果 git clone 出來的話,就是其中.git 的目錄),它是 git 用來儲存元資料和物件資料庫的地方。這個目錄非常重要,每次克隆映象倉庫的時候,實際拷貝的就是這個目錄裡面的資料

【三種狀態】

對於任何一個檔案,在 git 中都只有三種狀態:已提交(committed),已修改(modified)和已暫存(staged)

已提交:該檔案已經被安全地儲存在本地資料庫中了
已修改:修改了某個檔案,但還沒有提交儲存
已暫存:把已修改的檔案放在下次提交時要儲存的清單中

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

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

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

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

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

基本的 git 工作流程如下:

1、在工作目錄中修改某些檔案

2、對修改後的檔案進行快照,然後儲存到暫存區域

3、提交更新,將儲存在暫存區域的檔案快照永久轉儲到Git目錄中

【commit 雜湊值】

在儲存到 git 之前,所有資料都要進行內容的校驗和(checksum)計算,並將此結果作為資料的唯一標識和索引,而不是檔名

git 使用 SHA-1 演算法計算資料的校驗和,通過對檔案的內容或目錄的結構計算出一個SHA-1雜湊值,作為指紋字串。該字串由40個十六進位制字元(0-9及a-f)組成,看起來就像是:

23b9da6552252987aa493b52f8696cd6d3b00372

git 配置

配置級別

git 共有三個配置級別

  --local【預設,高優先順序】:隻影響本倉庫,檔案為.git/config

  --global【中優先順序】:影響到所有當前使用者的git倉庫,檔案為~/.gitconfig

  --system【低優先順序】:影響到全系統的git倉庫,檔案為/etc/gitconfig

基礎配置

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

1、使用者名稱

git config --global user.name "xiaohuochai"

2、郵箱

git config --global user.email "[email protected]"

3、文字編輯器

git config --global core.editor "code --wait"

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

Windows 使用回車(CR)和換行(LF)兩個字元來結束一行,而 Mac 和 Linux 只使用換行(LF)一個字元。下面的程式碼告訴 git 在提交時把回車和換行轉換成換行,檢出時不轉換。這樣在 Windows 上的檢出檔案中會保留回車和換行,而在 Mac 和 Linux 上,以及版本庫中會保留換行

git config --global core.autocrlf input

5、取消對中文的轉義

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

git config --global core.quotepath false

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

git config --global push.default simple

檢視配置

git config --list # 檢視所有配置
git config --list --global # 檢視全域性配置
git config user.name # 檢視某個配置項

如果要刪除或修改配置,更簡單的辦法是直接開啟~/.gitconfig檔案,或者.git/config檔案修改即可

關於忽略的配置

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

可以在專案根目錄建立一個名為 .gitignore 的檔案,列出要忽略的檔案模式

檔案 .gitignore 的格式規範如下:

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

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

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

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

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

.gitignore 檔案常見設定如下

node_modules/
ecosystem.json
.DS_Store
.idea
.vscode

SSH 配置

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

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

首先先確認一下是否已經有一個公鑰了。SSH公鑰預設儲存在賬戶的主目錄下的 ~/.ssh 目錄,有.pub字尾的檔案就是公鑰,另一個檔案則是金鑰

然後,使用如下命令來生成 SSH key,然後一路回車,使用預設值即可

$ ssh-keygen -t rsa -b 4096 -C [email protected]

如果一切順利的話,可以在使用者主目錄裡找到 .ssh 目錄,裡面有 id_rsaid_rsa.pub 兩個檔案,這兩個就是 SSH Key 的祕鑰對,id_rsa 是私鑰,不能洩露出去,id_rsa.pub 是公鑰,可以放心地告訴任何人

SSH的公鑰如下所示:

$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC3ltgCdqTIrPuN6yMYCeSMg8shtM+TRBIULDmfeh/9lE51e2g2t8ytLxz/QrPu3jvvpBqMimyPxC0NyW38eIHP9dkXTS0V76LlXy1MZvIjP3SnaU3AJs/fke61wc9y9EdPfrpSjIZpG7Z134+huaioLhPRShRmUQjl3plC9a89fnCyzTmtix5fDKKFjU3ZU6uVSDPy8+o+vsTfwAPQ1ylaBbY733Y1shmd6Texwmb8ttkv1Xj31RdhTdSS2eI3pSN/Ld1GC6/d2u3zcLnC6T4+1WLd0KTm/lqdzB2uWSsnMBI11wfKdw3pqEI17oGrPxurmunoMPzyR/dHwkfwotwh [email protected]

接下來,登陸 gitHub,開啟 Settings 中的 SSH Keys 頁面

然後,點 New SSH Key,填上任意 Title,在 Key 文字框裡貼上 id_rsa.pub 檔案的內容

點選 Add SSH key 按鈕後,即算配置完成了

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

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

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

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

git 基礎操作

初始化新倉庫

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

$ git init

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

檢查檔案狀態

要確定哪些檔案當前處於什麼狀態,可以用 git status 命令

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

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

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

現在建立一個新檔案README,儲存退出後執行 git status 會看到該檔案出現在未跟蹤檔案列表中

$ git status
On branch master

No commits yet

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

    README.txt

nothing added to commit but untracked files present (use "git add" to track)

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

跟蹤新檔案

使用命令 git add 開始跟蹤一個新檔案。所以,要跟蹤README檔案,執行

$ git add README.txt

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

$ git add .

此時再執行 git status 命令,會看到README檔案已被跟蹤,並處於暫存狀態

$ git status
On branch master

No commits yet

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

    new file:   README.txt

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

暫存已修改檔案

現在修改下之前已跟蹤過的檔案README.txt,將其內容修改為hello world

然後再次執行status命令,會看到這樣的狀態報告:

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

No commits yet

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

    new file:   README.txt

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

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

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

因此,將這個命令理解為“新增內容到下一次提交中”而不是“將一個檔案新增到專案中”要更加合適

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

$ git status
On branch master

No commits yet

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

    new file:   README.txt

提交更新

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

$ git commit

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


# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   new file:   README.txt
#
# Changes not staged for commit:
#   modified:   README.txt
#

可以看到,預設的提交訊息包含最後一次執行 git status 的輸出,放在註釋行裡,另外開頭還有一空行,需要輸入提交說明

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

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

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

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

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

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

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

將 README 內容中的 12345 去掉
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
# Changes to be committed:
#   modified:   README.txt
#
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
diff --git a/README.txt b/README.txt
index 5c1d8ad..95d09f2 100644
--- a/README.txt
+++ b/README.txt
@@ -1 +1 @@
-hello world12345
\ No newline at end of file
+hello world
\ No newline at end of file

輸出結果如下:

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

git 檢視

狀態簡覽

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

$ git status -s
 M README   # 檔案被修改,但還沒有放入暫存區
MM Rakefile # 在工作區被修改並提交到暫存區後又在工作區中被修改了
A  lib/git.rb # 新新增到暫存區中的檔案
M  lib/simplegit.rb # 檔案被修改,且放入了暫存區
?? LICENSE.txt # 新新增的未跟蹤的檔案

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

$ git status -sb
## master...origin/master [ahead 1]
 M "git.md"

狀態詳覽

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

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

下面的程式碼中,README.txt 檔案的內容從 'hello world1' 變化到 'hello world123'

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

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

下面的程式碼中,README.txt 檔案的內容從空內容變化到 'hello world1'

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

檢視提交歷史

使用 git log 命令可以檢視提交歷史

$ git log
commit 3f7b9ed403e6d624651014a5d15c481463572c15 (HEAD -> master)
Author: xiaohuochai <[email protected]>
Date:   Sun Dec 29 23:19:44 2019 +0800

    add b

commit ee5ae6f1dd5f620f4d2ac4a3702eb4814a062fce
Author: xiaohuochai <[email protected]>
Date:   Sun Dec 29 23:15:10 2019 +0800

    delete c

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

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

$ git log -p -2
commit 3f7b9ed403e6d624651014a5d15c481463572c15 (HEAD -> master)
Author: xiaohuochai <[email protected]>
Date:   Sun Dec 29 23:19:44 2019 +0800

    add b

diff --git a/b1 b/b1
new file mode 100644
index 0000000..e69de29

commit ee5ae6f1dd5f620f4d2ac4a3702eb4814a062fce
Author: xiaohuochai <[email protected]>
Date:   Sun Dec 29 23:15:10 2019 +0800

    delete c

diff --git a/c b/c
deleted file mode 100644
index e69de29..0000000

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

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

$ git log --oneline
3f7b9ed (HEAD -> master) add b
ee5ae6f delete c

git 命令歷史

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

$ git reflog

git 版本切換

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

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

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

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

 git reset --hard HEAD^
HEAD is now at ee5ae6f delete c

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

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

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

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

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

  下面使用 git reset --hard 命令,將檔案恢復到最新版本

$ git reset --hard e7422c8
HEAD is now at e7422c8 add b

git 分支管理

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

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

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

建立分支

建立一個新的分支指標。比如新建一個 testing 分支,可以使用 git branch 命令

$ git branch testing

這會在當前 commit 物件上新建一個分支指標

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

切換分支

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

$ git checkout testing

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

$ git checkout -b iss53

合併分支

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

1、快進(Fast forward)合併

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

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

2、無衝突合併

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

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

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

3、有衝突合併

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

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

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

$ 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")

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

<<<<<<< HEAD
<div id="footer">contact : [email protected]</div>
=======
<div id="footer">
  please contact us at [email protected]
</div>
>>>>>>> iss53

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

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

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

        modified:   index.html

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

Merge branch 'iss53'

Conflicts:
  index.html
#
# It looks like you may be committing a merge.
# If this is not correct, please remove the file
#       .git/MERGE_HEAD
# and try again.
#

檢視分支

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

$ git branch
  iss53
* master
  testing

若要檢視各個分支最後一個提交物件的資訊,執行 git branch -v

$ git branch -v
  iss53   93b412c fix javascript issue
* master  7a98805 Merge branch 'iss53'
  testing 782fd34 add scott to the author list in the readmes

刪除分支

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

$ git branch -d iss53

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

$ git branch -D iss53

git 遠端倉庫與分支

要參與任何一個 git 專案的協作,必須要了解該如何管理遠端倉庫。遠端倉庫是指託管在網路上的專案倉庫,同他人協作開發某個專案時,需要管理這些遠端倉庫,以便推送或拉取資料,分享各自的工作進展。管理遠端倉庫的工作,包括新增遠端庫,移除遠端庫,管理遠端庫分支,定義是否跟蹤這些分支等

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

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

克隆遠端倉庫

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

$ git clone [email protected]:littlematch0123/git_learn.git

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

$ git clone [email protected]:littlematch0123/git_learn.git learnGit

如果最後一個字元是點,表示會在當前目錄存放專案的所有檔案,但當前目錄一開始最好是個空目錄

$ git clone [email protected]:littlematch0123/git_learn.git .

檢視遠端倉庫

要檢視當前配置有哪些遠端倉庫,可以用 git remote 命令,它會列出每個遠端庫的簡短名字。在克隆完某個專案後,至少可以看到一個名為 origin 的遠端庫,git 預設使用這個名字來標識所克隆的原始倉庫

$ git remote
origin

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

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

新增遠端倉庫

通常情況下,一個本地 git 倉庫對應一個遠端倉庫;然而,在一些情況下,一個本地倉庫需要同時關聯多個遠端倉庫,比如同時將一個專案釋出在 github 和 coding上

新增一個新的遠端倉庫,可以指定一個名字,以便將來引用,執行 git remote add [shortname] [url]

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

推送本地分支

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

$ git push <遠端主機名> <本地分支名>:<遠端分支名>

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

$ git push origin serverfix:serverfix

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

git push origin serverfix:awesomebranch

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

$ git push origin serverfix

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

$ git push origin master

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

$ git push origin

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

$ git push

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

$ git push -u origin master

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

$ git push --all origin

從伺服器抓取資料

使用 git fetch 命令從伺服器抓取所有分支的資料

$ 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

如果加上分支名,則只更新該分支的資料

$ git fetch origin master

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

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

$ git merge origin/y

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

$ git checkout -b y origin/y

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

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

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

$ git pull <遠端主機名> <遠端分支名>:<本地分支名>

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

$ git pull origin next:master

如果遠端分支(next)要與當前分支合併,如下

$ git pull origin next

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

$ git pull origin

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

$ git pull

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

刪除遠端分支

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

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

$ git push origin :x
# 等同於
$ git push origin --delete x

遠端倉庫刪除和重新命名

$ git remote rename coding cd # 重新命名
$ git remote rm coding # 刪除

不區分遠端倉庫

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

先檢視當前的 git remote 情況

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

接下來,不額外新增遠端倉庫,而是給現有的遠端倉庫新增額外的URL

使用 git remote set-url --add <name> <url>,給已有的遠端倉庫新增一個遠端地址

$ git remote set-url --add origin [email protected]:ehuo0123/git_learn.git

再次檢視所關聯的遠端倉庫:

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

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

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

$ git remote set-url --delete origin [email protected]:ehuo0123/git_learn.git

git 其他操作

刪除檔案

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

touch a # 新建 a
rm a # 刪除 a

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

$ git rm a
fatal: pathspec 'a' did not match any files

2、從暫存區中刪除檔案,需要使用 git rm -f 命令來強制刪除

touch b # 新建 b
git add b # 將 b 新增到暫存區
git rm -f b # 刪除 b

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

$ git rm b
error: the following file has changes staged in the index:
    b
(use --cached to keep the file, or -f to force removal)

3、從本地倉庫中刪除檔案,使用git rm命令即可

touch c # 新建 c
git add c # 將 c 新增到暫存區
git commit -m 'add c' # 提交到本地倉庫
git rm c # 刪除 c

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

$ git rm d --cached

檔案重新命名

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

touch a # 新建 a
mv a a1 # 重新命名 a 為 a1

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

$ git mv a a1
fatal: not under version control, source=a, destination=a1

2、從暫存區,或者本地倉庫中重新命名檔案,直接使用 git mv 命令就可以了

$ git mv b1 b2
localhost:t bailiang$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    b1 -> b2

撤消操作

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

1、修改最後一次提交

有時候提交完了才發現漏掉了幾個檔案沒有加,或者提交資訊寫錯了。想要撤消剛才的提交操作,可以使用 --amend 選項重新提交:

$ git commit --amend

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

$ git commit -m 'initial commit'
$ git add forgotten_file
$ git commit --amend

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

2、取消已暫存的檔案
使用 git reset HEAD <file>... 命令可以取消暫存,將暫存區的檔案恢復到工作目錄中

$ git reset HEAD a.txt

3、取消對檔案的修改

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

$ git checkout -- a.txt

注意事項

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

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

當然,辦法也是有的,需要安裝 docx2txt 程式,將 word 文件轉換為可讀的文字檔案

把下面這行文字加到 .gitattributes 檔案中:

*.docx diff=word

寫一個指令碼把輸出結果包裝成 git 支援的格式。 在可執行路徑下建立一個叫 docx2txt 檔案,新增這些內容:

#!/bin/bash
docx2txt.pl $1 -

chmod a+x 給這個檔案加上可執行許可權。 最後,需要配置 git 來使用這個指令碼

$ git config diff.word.textconv docx2txt

現在如果在兩個快照之間進行比較,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 中任何已提交的東西幾乎總是可以恢復的,但任何未提交的東西丟失後很可能再也找不到了

常用命令

基礎操作

$ git init  #初始化倉庫
$ git add <file> #跟蹤新檔案,或者把已跟蹤的檔案放到暫存區
$ git add .  #批量跟蹤所有工作目錄下未被跟蹤的檔案
$ git rm <file> #從本地倉庫中刪除檔案
$ git rm -f <file> #從暫存區中刪除檔案
$ git rm --cached <file> #從git倉庫中刪除,但保留在當前工作目錄中
$ git commit  #把檔案提交到本地倉庫
$ git commit -m 'wrote a file'  #-m引數後跟提交說明的方式,在一行命令中提交更新
$ git commit -am 'wrote a file'  #把所有已經跟蹤過的檔案暫存起來一併提交
$ git commit -v #啟動文字編輯器以便輸入本次提交的說明,編輯器會顯示與上次提交相比的變更之處
$ git commit --amend  #修改最後一次提交
$ git reset HEAD <file>  #取消暫存
$ git checkout -- <file>  #恢復檔案內容

檢視操作

$ git status  #檢查當前檔案狀態
$ git status -s #更為緊湊的格式的狀態輸出
$ git diff  #檢視工作目錄與暫存區的差異
$ git diff --cached  #檢視暫存區與某次提交的差異,預設為HEAD
$ git diff id1 id2  #檢視兩次提交之間的差異
$ git log  #檢視提交歷史
$ git log -p #展開顯示每次提交的內容差異
$ git log -2 #僅顯示最近的兩次更新
$ git log --oneline #每個提交放在一行顯示
$ git log --all #顯示所有分支的提交記錄
$ git log --graph  #顯示 ASCII 圖形表示的分支合併歷史
$ git reflog  #按照之前經過的所有的commit路徑按序來排列,用來記錄每一次命令

分支操作

$ git branch  #列出所有分支,當前分支前面會標一個*號
$ git branch -v  #檢視各分支最後一個提交物件的資訊
$ git branch <branchName>  #新建分支
$ git branch -d <branchName>  #刪除分支
$ git branch -D <branchName>  #強制刪除分支,用於刪除沒有合併過的分支
$ git checkout <branchName>   #分支切換
$ git checkout -b <branchName>  #建立新分支並切換到該分支
$ git checkout -  #將HEAD移動到上一分支
$ git merge <branchName>  #將目標分支合併到當前分支
$ git reset --hard <commit>  #將當前分支回退到歷史某個版本,提交的內容會複製到暫存區和工作目錄

遠端操作

$ git remote   #檢視所有的遠端倉庫
$ git remote -v  #顯示遠端倉庫對應的克隆地址
$ git remote add [shortname] [url]  #新增一個新的遠端倉庫
$ git remote rename pb paul   #將遠端庫的名稱從pb改為paul
$ git remote rm [shortname]   #取消對該遠端庫的關聯
$ git remote set-url --add <name> <url>  #給現有的遠端倉庫新增額外的URL
$ git remote set-url --delete <name> <url>  #給現有的遠端倉庫刪除額外的URL
$ git clone <address>  #克隆遠端倉庫的所有分支
$ git push origin <branchName>  #取出在本地的<branchName>分支,推送到遠端倉庫的<branchName>分支
$ git fetch origin  #從遠端伺服器抓取所有分支的資料
$ git pull origin <branchName>  #相當於fetch和merge命令的合體
$ git push origin :serverfix  #在伺服器上刪除serverfix分支
$ git push origin --delete serverfix  #刪除伺服器分支的另外寫法