今天簡單講下 Git 的實(shí)現(xiàn)原理，知其所以然才能知其然；并且梳理了日常最常用的 12 個(gè)命令，分為三大類分享給你。

本文的結(jié)構(gòu)如下：

1. 作者和開發(fā)原由

2. Git 的數(shù)據(jù)模型

3. 常用命令

4. 資源推薦

作者和開發(fā)原由

Talk is cheap. Show me the code.

這句話就出自 Linux 和 Git 的作者
Linus Torvalds。

原本 Linux 內(nèi)核的版本控制系統(tǒng)是用的 BitKeeper，然而 2005 年，BitMover 公司不再讓 Linux 開發(fā)團(tuán)隊(duì)免費(fèi)使用了。。

Linus 一聽，不給用了？老子自己寫！

于是，大佬十天之內(nèi)完成了 Git 的第一個(gè)版本。

所以 Git 是一個(gè)免費(fèi)的、開源的版本控制系統(tǒng)。

版本控制系統(tǒng)

版本控制其實(shí)每個(gè)人都用過，那些年修改過的簡歷：

小齊簡歷 2012 版
小齊簡歷 2013 版
小齊簡歷 2014 版
小齊簡歷 2015 版
小齊簡歷 2016 版
小齊簡歷 2017 版
小齊簡歷 2018 版
小齊簡歷 2019 版
...

還有那些年打死都不再改的畢業(yè)論文：

畢業(yè)論文最終版
畢業(yè)論文最最終版
畢業(yè)論文最最最終版
畢業(yè)論文最最最最終版
畢業(yè)論文最終不改版
畢業(yè)論文最終真不改版
畢業(yè)論文最終真真不改版
畢業(yè)論文最終打死不改版
畢業(yè)論文最終打死不改版 2
...

沒錯(cuò)，這就是本地版本控制系統(tǒng)。

很明顯，好處是簡單，但是只能一個(gè)人在這改，無法和他人完成合作。那么以下兩種主流的版本控制系統(tǒng)應(yīng)運(yùn)而生。

1. 集中化版本控制系統(tǒng)

Centralized Version Control Systems (CVCS)

比如：CVS, Subversion, Perforce, etc.

這種版本控制系統(tǒng)有一個(gè)單一的集中管理的服務(wù)器，保存所有文件的最新版本，大家可以通過連接到這臺服務(wù)器上來獲取或者提交文件。

這種模式相對本地版本控制系統(tǒng)是有所改進(jìn)的，但是缺點(diǎn)也很明顯，如果服務(wù)器宕機(jī)，那么輕則耽誤工作、重則數(shù)據(jù)丟失。于是分布式版本控制系統(tǒng)應(yīng)運(yùn)而生。

2. 分布式版本控制系統(tǒng)

Distributed Version Control Systems (DVCS)

比如：Git, Mercurial, Bazaar, etc.

分布式的版本控制系統(tǒng)會把代碼倉庫完整地鏡像下來，這樣任何一個(gè)服務(wù)器發(fā)生故障，都可以用其他的倉庫來修復(fù)。

更進(jìn)一步，這種模式可以更方便的和不同公司的人進(jìn)行同一項(xiàng)目的開發(fā)，因?yàn)閮蓚€(gè)遠(yuǎn)程代碼倉庫可以交互，這在之前的集中式系統(tǒng)中是無法做到的。

那么什么叫“把代碼倉庫完整地鏡像下來”呢？

CVCS 每個(gè)版本存放的是當(dāng)前版本與前一個(gè)版本的差異，因此也被稱作基于差異的版本控制 (delta-based)；

Git 存儲的是所有文件的一個(gè)快照 (snapshot)，如果有的文件沒有修改，那就只保留一個(gè) reference 指向之前存儲的文件。

不是很好理解？那接著看吧～

Git 的數(shù)據(jù)模型

1. 什么是快照 (snapshot) 呢？

首先我們來學(xué)兩個(gè) Git 中的術(shù)語：

• blob, 就是單個(gè)的文件；
• tree, 就是一個(gè)文件夾。

快照則是被追蹤的最頂層的樹。

比如我的“公眾號”文件夾的這么一個(gè)結(jié)構(gòu)：

那么一個(gè)快照就是追蹤的“公眾號”這顆樹。

2. 本地庫的數(shù)據(jù)模型

Git 記錄了每個(gè)快照的 parent，也就是當(dāng)前這個(gè)文件夾的上一個(gè)版本。

那么快照的迭代更新的過程就可以表示為一個(gè)有向無環(huán)圖

每個(gè)快照其實(shí)都對應(yīng)了一次 commit，我們用代碼來表示一下：

class commit {
  array parents
  String author
  String message
  Tree snapshot
}

這就是 Git 的數(shù)據(jù)模型。

blob, tree, snapshot 其實(shí)都一樣，它們在 Git 中都是對象，都可以被引用或者被搜索，會基于它們的 SHA-1 hash 進(jìn)行尋址。

git cat-file -t: 查看每個(gè) SHA-1 的類型;
git cat-file -p: 查看每個(gè)對象的內(nèi)容和簡單的數(shù)據(jù)結(jié)構(gòu)。

但是通過這個(gè)哈希值來搜索也太不方便了，畢竟這是一串 40 位的十六進(jìn)制字符，就是第二部分 git log 里輸出的那個(gè)編碼。

因此，Git 還給了一個(gè)引用 reference。

比如，我們常見的 HEAD 就是一個(gè)特殊的引用。

本地庫就是由 對象 和 引用 構(gòu)成的，或者叫 Repositories.

在硬盤上，Git 只存儲 對象 和 引用，所有的 Git 命令都對應(yīng)提交一個(gè)快照。

那有哪些常用命令呢？

常用命令

本章分三大部分介紹日常常用命令：

• 本地操作
• 和遠(yuǎn)程庫的交互
• 團(tuán)隊(duì)協(xié)作 - 分支

本地操作

在學(xué)習(xí)常用命令之前，你首先需要知道的 Git 的「三個(gè)分區(qū)」和對應(yīng)的文件的「三種狀態(tài)」：

• 工作區(qū)：就是你本地實(shí)際寫代碼的地方，無論你是用 vim 直接改也好，還是在 IDE 里寫，都無所謂。

• 對應(yīng)的文件狀態(tài)是：modified，已修改，但還沒保存到數(shù)據(jù)庫中。

• 暫存區(qū)：就是臨時(shí)存放的地方。

• 對應(yīng)的文件狀態(tài)是：staged，Git 已經(jīng)對該文件做了標(biāo)記，下次提交知道要包含它。

• 本地庫：存放本地歷史版本信息。

• 對應(yīng)的文件狀態(tài)是：committed，文件已經(jīng)安全的保存在本地?cái)?shù)據(jù)庫中。

1. $ git add

工作區(qū)改完了代碼，就用 git add 提交到暫存區(qū)。

這里如果文件改動的比較多，但又不是每個(gè)都需要提交，我會設(shè)置 git ignore file，就表示這些文件不要提交，比如在 build project 的時(shí)候會自動生成的那些文件等等。

2. $ git commit -m "comment"

從暫存區(qū)提交到本地庫，就需要用 commit。

一般后面都會跟個(gè) -m 加句 comment，簡單說下改動的內(nèi)容或者原因，我們公司大家默認(rèn)也會把 Jira鏈接附上，這樣就知道這個(gè)改動對應(yīng)哪個(gè)任務(wù)。

那如果想再改，再重新 git add 即可，但是 commit 這句需要改成

$ git commit --amend

這樣就還是一條 git log 信息。

3. $ git log

git log 可以查看到提交過的信息，從近到遠(yuǎn)顯示每次 commit 的 comment 還有作者、日期等信息，比如大概長這個(gè)樣子：

commit 5abcd17dggs9s0a7a91nfsagd8ay76875afs7d6
Author: Xiaoqi
Date: xxx xxx xxx
改了 Test 文件

commit 后面的這個(gè)編號，是每次歷史記錄的一個(gè)索引。比如如果需要對版本進(jìn)行前進(jìn)或者后退的時(shí)候，就需要用到它。

這樣打印的 log 太多，更簡潔的打印方式是：

$ git log --oneline

就一行打印出來了。

或者：

$ git reflog

更常用一些。

4. $ git reset

那我們剛剛說過，如果需要前進(jìn)或退回到某個(gè)版本，就用

$ git reset --hard <編號>

這樣就直接跳到了這個(gè)編號對應(yīng)的那個(gè)版本。

那么這個(gè) hard 是什么意思呢？

這里有 3 個(gè)參數(shù)：hard, soft, mixed，我們一一來說一下。

回到我們最重要的這張圖上來：

我們剛剛說的前進(jìn)或后退到某一版本，是對本地庫進(jìn)行的操作。

那有個(gè)問題：
本地庫的代碼跳到那個(gè)版本之后，工作區(qū)和暫存區(qū)的代碼就和本地庫的不同步了呀！

那這些參數(shù)就是用來控制這些是否同步的。

$ git reset --hard xxx

三個(gè)區(qū)都同步，都跳到這個(gè) xxx 的版本上。

$ git reset --soft xxx

前面兩個(gè)區(qū)不同步，就只有本地庫跳到這個(gè)版本。

$ git reset --mixed xxx

暫存區(qū)同步，工作區(qū)不動。

所以呢，用的多的就是 hard.

遠(yuǎn)程交互

和遠(yuǎn)程庫的交互主要是推、拉，也就是寫入和讀取。

5. $ git push

小齊寫完了代碼，要提交到公司的代碼庫里，這個(gè)過程要用 git push.

當(dāng)然了，這么用會被打的。。畢竟還要 cr 呢。

5. $ git clone

新來的實(shí)習(xí)生首先要 clone 整個(gè)項(xiàng)目到本地來，然后才能增刪改查。

當(dāng)然了實(shí)際工作中也沒人這么用。。因?yàn)槊考夜径紩凶约喊b的工具。不過如果是做 Github 上的開源項(xiàng)目，就用得上了。

6. $ git pull

小齊提交了新的代碼之后，領(lǐng)導(dǎo)要審查呀，所以用 git pull 把最新的代碼拉取下來瞅瞅。

實(shí)際上呢，

git pull = fetch + merge

7. $ git fetch

git fetch 這個(gè)操作是將遠(yuǎn)程庫的數(shù)據(jù)下載到本地庫，但是工作區(qū)中的文件沒有更新。

而要談 get merge，我們還需要先講下分支。

merge 是 git pull 默認(rèn)的選項(xiàng)，合并其實(shí)還有另外一種方法：rebase，中文叫做變基。

8. $ git rebase

rebase 的作用更多的是來整合分叉的歷史，可以將某個(gè)分支上的所有修改都移到另一分支上，就像是變了基底。

分支與合并

首先我們來看幾個(gè)關(guān)于分支的基本操作：

9. 查看分支：

$ git branch

類似于ls，能夠列出當(dāng)前所有分支。

git branch -v 能夠顯示更多信息。

10. 創(chuàng)建分支：

$ git branch

11. 切換分支：

$ git checkout

有了分支之后必然會有合并：

12. 合并分支：

$ git merge

而合并時(shí)就可能會有沖突，什么時(shí)候會有沖突呢？

在同一個(gè)文件的同一個(gè)位置修改時(shí)。

因?yàn)?Git 會努力的把你們改動不同的地方合并在一起，但如果實(shí)在是在同一個(gè)地方改的，那它也沒辦法了，只能留給程序員去手動處理了。

當(dāng)然了，每個(gè)命令延伸下去還有無限多個(gè)，本文不可能涵蓋全部，所以在此重磅推薦齊姐精心挑選的三大學(xué)習(xí)資源，大家可以自行享用～

學(xué)習(xí)資源

git help

其實(shí)我個(gè)人使用最多的是git help

真心方便又好用啊！

比如 git help pull:

先介紹了有哪些參數(shù)，然后 description 詳細(xì)解釋了它的工作原理，下面還有圖解，有木有太香！！

不過這種方式更像是 cheatsheet，當(dāng)你已經(jīng)知道了這個(gè)命令、只是忘了它的用法的時(shí)候去查。

如果你想系統(tǒng)的學(xué)習(xí)，那么下面 ? 的更適合你。

Pro Git

這本書是強(qiáng)烈推薦了！！

Pro Git 這本書不僅講了 Git 的基礎(chǔ)用法、高級用法，以及最后還深入講解了 Git 的原理，非常細(xì)致全面。

書的電子版也能在網(wǎng)站上直接下載。

英文版：

• https://git-scm.com/book/en/v2

中文版：

• https://git-scm.com/book/zh/v2

玩游戲

Practice makes perfect!

推薦一個(gè)寶藏資源：玩游戲來練 Git

項(xiàng)目：https://github.com/pcottle/learnGitBranching

網(wǎng)址：https://learngitbranching.js.org/

我熟悉很多工具都是通過小游戲來練習(xí)的，比如 vim 的操作，還是蠻推薦這種方式的。就不劇透啦，大家自己去探索吧～