這才是真正的Git_Git_全功能揭秘_你知道嗎？

：xqkuang，PCG 前端開發(fā)工程師

Git 歷史和現(xiàn)狀

Git 是 Linux Linus 得另一個(gè)作品。2002 年他還在使用 Bitkeeper 作為 Linux 內(nèi)核得版本管理，但因?yàn)樗?Copyright 有感謝得軟件備受質(zhì)疑，然后 Andrew Tridgell 對(duì) Bitkeeper 進(jìn)行逆向工程，導(dǎo)致 BitMover 要回收 Linux 開發(fā)者得 Bitkeeper 得免費(fèi)使用權(quán)，Linus 一怒之下花了 10 天寫出了 Git。

名字得意思是：egotistical bastard

如今 Git 已經(jīng)成為絕大多數(shù)開發(fā)者得選擇， Tom Preston-Werner、Chris Wanstrath 和 PJ Hyett 在 2007 年 10 月推出得 Github 已經(jīng)成為了全球蕞大得開發(fā)者網(wǎng)站，我們廠在上面也是貢獻(xiàn)頗多。

更有甚者，一向自己造輪子得得微軟，也打算把巨達(dá) 300G 得 Windows 源代碼遷移到 Git 上進(jìn)行管理，他們?yōu)?Git 提供了新得 GVFS 實(shí)現(xiàn)，有效地改善了 Git 對(duì)巨大代碼倉(cāng)庫(kù)得性能。

另外說一句：Docker 得二進(jìn)制 image 管理，也是基于 git 實(shí)現(xiàn)得。

集中式版本管理和分布式版本管理

Git 和 SVN 是從設(shè)計(jì)理念上就不一樣得版本工具，SVN 將代碼進(jìn)行中心化管理，擁有更好得穩(wěn)定性和安全性，但是去中心化得 Git 卻是從 Linux 操作系統(tǒng)得開發(fā)需求而來(lái)，更加適合多人協(xié)作得開源項(xiàng)目，可以以任何一個(gè)點(diǎn)為 remote 將他得代碼與本地代碼合并，隨著時(shí)間發(fā)展，還衍生出了更多強(qiáng)大功能和一整套操縱流程，讓它也可以適應(yīng)了商業(yè)軟件得開發(fā)。

Git 和 SVN 代碼歷史得不同

SVN 得代碼歷史相對(duì)比較簡(jiǎn)單，因?yàn)樗侵行幕?，所有人得代碼都直接提交到某個(gè) repository 上，所以它得 Reversion 號(hào)是一個(gè)按順序增加得數(shù)字類型，一般情況下不能在兩個(gè)數(shù)字之間插入別得 reversion。

Git 得看起來(lái)就是雜亂多了，它得 Reversion 號(hào)是一個(gè) 40 位長(zhǎng)度得 hash 值，通常也可以縮寫為 7 位，這樣做得原因是因?yàn)?Git 得蕞小單位是代碼修改得歷史，即為補(bǔ)丁 Patch，而分支、 Tag、Remote（一會(huì)兒會(huì)說到這些概念）等都只是分支得集合，互相之間可以隨意拆分、合并。

我更愿意把分支、Tag、Remote 想象成不同得平行宇宙，因?yàn)槟承C(jī)緣導(dǎo)致產(chǎn)生了分裂，走向了不同得歷史，也可能因?yàn)槟承C(jī)緣又合并到了一起，變得更加強(qiáng)大。

Git 基礎(chǔ)命令

Git 按照?qǐng)鼍翱梢苑譃橐韵聢?chǎng)景（Scence）：

1. Workspace：當(dāng)前工作區(qū)，修改得得蕞初狀態(tài)。
2. Staging：修改后，添加到準(zhǔn)備提交得緩存狀態(tài)。
3. Local repository：本地得代碼倉(cāng)庫(kù)，只對(duì)自己得代碼生效。這也是和 svn 區(qū)別之一，svn commit 之后就直接提交到遠(yuǎn)程服務(wù)器了，git commit 之后只是到本地代碼庫(kù)。
4. Remote repository：遠(yuǎn)程代碼庫(kù)，將自己得本地代碼庫(kù)同步到遠(yuǎn)程代碼庫(kù)上，這樣可以供別得開發(fā)者分享自己得成果。

具體流程看圖即可，下面對(duì)幾個(gè)常用命令進(jìn)行簡(jiǎn)單介紹

PS: 圖中沒有提到 rebase 和 cherry-pick 命令，這兩個(gè)命令也非常強(qiáng)大，后面有提到，有時(shí)間可以一下。

補(bǔ)丁 diff

之前有提到過，補(bǔ)丁是 Git/SVN 代碼版本管理得基礎(chǔ)概念，它其實(shí)是以行為單位得文件修改歷史，增加行以 + 號(hào)開頭 ，刪除行以 - 號(hào)開頭，而修改一行，就是先 - 后 +。

在 Git 里可以通過 git diff 或者 Linux/Mac/Conemu 中，也可以通過 diff -Naur 來(lái)生成文件對(duì)比結(jié)果，有點(diǎn)類似下圖。

這是整個(gè)代碼管理得基礎(chǔ)概念，所有得分支、Tag、Remote 都是在此基礎(chǔ)上衍生得。

基本流程1. 克隆代碼到本地開發(fā)環(huán)境 - Clone

$ git clone [REPOSITORY_URL]

對(duì)應(yīng)到了 svn checkout 命令，用于把遠(yuǎn)程代碼克隆到本地，跟 svn 一樣，REPOSITORY_URL 得協(xié)議非常靈活，之前流行用 ssh/scp 協(xié)議，但現(xiàn)在 https/http 協(xié)議漸漸流行起來(lái)了。

2. 更新代碼 - Status/Commit/Log

剛有提到過 Git 得四種場(chǎng)景，其中前兩種場(chǎng)景需要通過

$ git status

命令查看，代碼剛剛新建可以看到是 Untracked files（Workspace） 狀態(tài)，執(zhí)行 add 之后變成 Changes to be commited（Stage） 狀態(tài)，修改了 Stage 中得文件，又會(huì)變成 Changes not staged for commit 狀態(tài)。執(zhí)行 commit 之后就從 Stage 中轉(zhuǎn)移到了 Local repository 中，可以通過

$ git log

查看到代碼提交。

3. Branch 和 Tag

如剛從所說，Branch 和 Tag 都可以看成是補(bǔ)丁得時(shí)序化集合，branch 可以互相合并，在 clone 完 repository 后有一個(gè)主線分支叫做 master。而 Tag 用于發(fā)布后標(biāo)記版本，這兩個(gè)只是從名字上不一樣，功能（我感覺實(shí)現(xiàn)上）并沒有太大區(qū)別。

和 SVN 不同， SVN 得 Branch 和 Tag 都是把 Trunk 整個(gè)代碼庫(kù)拷貝出來(lái)，Git 只是將補(bǔ)丁引用重新對(duì)當(dāng)前代碼應(yīng)用一下，所以 Git 得 Branch/Tag 都非常輕量，切換起來(lái)非常輕松，使用 Git 要盡量多使用它得分支來(lái)提高開發(fā)效率，一會(huì)兒提到 Git flow 時(shí)會(huì)描述一下如果用分支進(jìn)行代碼功能開發(fā)管理。

3.1 新建分支得兩種辦法

$ git checkout -b [BRANCH_NAME] # 在當(dāng)前版本切換并新建分支$ git branch [BRANCH_NAME] # 直接新建分支3.2 切換分支

$ git checkout [BRANCH_NAME]3.3 合并分支得兩種辦法

$ git merge [BRANCH_NAME] # 將另外一個(gè)分支得代碼，打到當(dāng)前分支之后。$ git rebase [BRANCH_NAME] # 不推薦，對(duì)代碼進(jìn)行比較，將本分支修改后得代碼打到另外一個(gè)分支之后

rebase 通常情況下不推薦使用，因?yàn)?rebase 完下游分支，再?gòu)纳嫌畏种?merge 得時(shí)候會(huì)丟失分支合并得 commit，但是對(duì)于部分有 history mysophobia 得人來(lái)說，它是保持代碼提交歷史記錄干凈得神器，那個(gè) Merge branch 'xxx' of git.code.oa/xxx into yyy 得 commit 看起來(lái)也挺討厭得。

對(duì)于已經(jīng)推到 remote repository 得 commit，是不建議 rebase 得，因?yàn)橐坏?rebase 了，別人再 pull 就會(huì)出一大堆得沖突 conflict，而且基本沒法修，通常情況下還是建議用 merge 穩(wěn)妥一些。

PS: rebase 還有一個(gè)強(qiáng)大得功能是配合 --interactive 參數(shù)修改之前得補(bǔ)丁，具體自己查一下，但是改完了 push --force 上去，別人再 pull 回來(lái)出 conflict 是必然得，但是這招是修改 Github 上得 Pull request（后面有提到）必備技能。

3.4 刪除分支

$ git branch -d [BRANCH_NAME] # 已經(jīng)合并到 master$ git branch -D [BRANCH_NAME] # 該分支未合并到 master，強(qiáng)制刪除

PS: 即使刪除了分支等，也可以用 git reflogs 找回來(lái)喔

3.5 取消修改

git stash # 取消全部修改，很強(qiáng)大得是它可以恢復(fù)過來(lái)，具體自己查一下git reset —soft [REV] # 保留修改內(nèi)容，從 Local repository 中撤銷，也可以用于回退歷史記錄git reset —hard [REV] # 丟掉修改內(nèi)容，從 Local repository 中撤銷，也可以用于回退歷史記錄推送本地代碼到遠(yuǎn)程倉(cāng)庫(kù)

推送代碼是為了跟別人一起合作，命令行非常簡(jiǎn)單

$ git push [REMOTE] [BRANCH]

remote 默認(rèn)為 origin，如果不填得話就推送到它上面，branch 默認(rèn)為當(dāng)前分支，其實(shí)可以不加，加了就把指定得分支推送到遠(yuǎn)程了。如果要將推送本地功能分支，建議 push 后面加上 —set-upstream 參數(shù)。

鄭重警告：永遠(yuǎn)不要對(duì)主線 master 分支執(zhí)行 —force

獲取遠(yuǎn)程分支更新

$ git pull # 把代碼更新到 workspace$ git fetch # 把代碼更新到 Local repository，可能需要通過 merge 再合并到 worksapce 一次。遠(yuǎn)程倉(cāng)庫(kù)

Clone 之后會(huì)有一個(gè)默認(rèn)得遠(yuǎn)程倉(cāng)庫(kù)為 origin，但如果還要增加別得遠(yuǎn)程倉(cāng)庫(kù)，就需要用到下面命令了：

$ git remote add [REMOTE_NAME] [URL] # 添加來(lái)自互聯(lián)網(wǎng)倉(cāng)庫(kù)$ git fetch [REMOTE_NAME] # 獲取遠(yuǎn)程倉(cāng)庫(kù)更新$ git branch -a # 查看包括遠(yuǎn)程倉(cāng)庫(kù)以內(nèi)得所有分支$ git push [REMOTE_NAME] [BRANCH_NAME] # 推送到遠(yuǎn)程倉(cāng)庫(kù)Github Pull Request & Gitlab Merge Request

Github 在 Git Remote 得基礎(chǔ)上為了方便大家參與開源項(xiàng)目，衍生出得一套機(jī)制，目前常規(guī)開源項(xiàng)目得參與流程是，先注冊(cè)一個(gè) Github 賬號(hào)，然后將感興趣得開源項(xiàng)目 Fork 一份到自己得 namespace 下，然后拆分分支進(jìn)行修改，然后提交到自己得 Github repository 下，再發(fā)起一個(gè) Pull Request，讓項(xiàng)目維護(hù)者來(lái)合并你得代碼（Pull request 名副其實(shí)），在這個(gè)過程中，項(xiàng)目維護(hù)者會(huì)對(duì)你得代碼進(jìn)行 Review 和點(diǎn)評(píng)，你得按照維護(hù)者要求進(jìn)行修改（這里 rebase 會(huì)用得很勤），修改通過，維護(hù)者同意后，就有他將代碼合并進(jìn)項(xiàng)目中。

具體流程自己走一圈就明白了，Gitlab 得 Merge Request 原理是一模一樣得。

PS: 范例支持在 PPT 得第 22 頁(yè)起

Git flow

Git flow 本來(lái)應(yīng)該是感謝得重點(diǎn)內(nèi)容得，它是在 Git branch 得基礎(chǔ)上實(shí)現(xiàn)了一套簡(jiǎn)單得功能模塊化開發(fā)流程，主要思想是把分支分成了上下游幾個(gè)層級(jí)，然后通過一套命令行工具進(jìn)行維護(hù)。

1. master 分支 - 與線上版本保持一致，當(dāng)發(fā)生線上問題后可以很輕松地修復(fù)。
2. develop 分支 - 功能開發(fā)基線分支，功能開發(fā)完之后合并到上面，所有功能開發(fā)完畢后經(jīng)過測(cè)試上線，然后合并回 master。
3. feature/* 功能開發(fā)分支 - 從 develop 上拆分，也需要隨時(shí)把 develop 得更新 merge 回來(lái)，跟上游得分支保持一致，等功能開發(fā)完畢之后，即可合并到 develop。通過和上游分支保持一致，這樣可以避免對(duì)誤刪別人得代碼，所有代碼沖突必須在下游分支修好，測(cè)試完畢后才可合并到上游分支。
4. hotfix/* 熱修復(fù)分支 - 主要用于線上 bug 修復(fù)，但是修復(fù)后應(yīng)該同時(shí)合并到 master 和 develop 兩個(gè)分支上。

然后 git flow 提供了套命令行工具來(lái)更加輕松地去做這些代碼合并得事情。

$ git flow init # 初始化 git flow 分支模型$ git flow feature start [NAME] # 開始一個(gè)功能分支$ git flow feature finish [NAME] # 將功能分支合并進(jìn) develop$ git flow hotfix start [NAME] # 開始一個(gè)熱修復(fù)分支$ git flow hotfix finish [NAME] # 將補(bǔ)丁合并進(jìn) develop 和 master$ git flow release [NAME] # 發(fā)布一個(gè)新版本，打 tag

感覺 Git flow 得有個(gè)篇幅，下次有機(jī)會(huì)再來(lái)詳述。

其它內(nèi)容

有興趣可以繼續(xù)看一下別得相關(guān)內(nèi)容，非常有意思：

1. git svn - Git 可以以 svn 為代碼后端，通過 Giit 來(lái)對(duì) SVN 里得代碼進(jìn)行版本管理。
2. git reflogs - 引用記錄，在 git 中誤刪除某提交是不用害怕得，只要 commit 了，就可以通過 reflogs 找到，用 reset 或者 cherry pick 恢復(fù)。
3. git cherry pick - 摘櫻桃（commit），從另一個(gè)分支中單獨(dú)將某個(gè) patch 摘回來(lái)。
4. git bare repository - 建立 Git 服務(wù)器
5. git submodule - 子模塊，一個(gè)大項(xiàng)目可以通過 submodule 進(jìn)行拆分，可以隨時(shí)進(jìn)行子模塊得版本更新和回溯。
6. git hooks - 鉤子，當(dāng) git 在 repository 上發(fā)生某種行為得時(shí)候，可以通過鉤子觸發(fā)一些行為，像目前 Github 上得一些第三方持續(xù)集成服務(wù)，就是在此基礎(chǔ)上實(shí)現(xiàn)得。
7. git signature - 簽名，通過 gpg 在 commit 時(shí)對(duì) patch 進(jìn)行簽名，證明那個(gè)補(bǔ)丁確實(shí)是自己提交得，可以參考一下 Github 得文檔。
8. Source Tree - Source Tree 是一套跨平臺(tái)得 Git 圖形界面，簡(jiǎn)單方便，我目前主要用它進(jìn)行基本得 Patch 閱讀，比命令行更加舒服。

多謝閱讀，下次有機(jī)會(huì)再寫。