Git 全功能介紹

作者：xqkuang，PCG 前端開發工程師

Git 歷史和現狀

Git 是 Linux 作者 Linus 的另一個作品。2002 年他還在使用 Bitkeeper 作爲 Linux 內核的版本管理，但因爲它是 Copyright 有版權的軟件備受質疑，然後 Andrew Tridgell 對 Bitkeeper 進行逆向工程，導致 BitMover 要回收 Linux 開發者的 Bitkeeper 的免費使用權，Linus 一怒之下花了 10 天寫出了 Git。

名字的意思是：egotistical bastard

如今 Git 已經成爲絕大多數開發者的選擇， Tom Preston-Werner、Chris Wanstrath 和 PJ Hyett 在 2007 年 10 月推出的 Github 已經成爲了全球最大的開發者網站，我們廠在上面也是貢獻頗多。

Tencent at Github

更有甚者，一向自己造輪子的的微軟，也打算把巨達 300G 的 Windows 源代碼遷移到 Git 上進行管理，他們爲 Git 提供了新的 GVFS 實現，有效地改善了 Git 對巨大代碼倉庫的性能。

Microsoft will migrate windows source code to git

另外說一句：Docker 的二進制 image 管理，也是基於 git 實現的。

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

Git 和 SVN 是從設計理念上就不一樣的版本工具，SVN 將代碼進行中心化管理，擁有更好的穩定性和安全性，但是去中心化的 Git 卻是從 Linux 操作系統的開發需求而來，更加適合多人協作的開源項目，可以以任何一個點爲 remote 將他的代碼與本地代碼合併，隨着時間發展，還衍生出了更多強大功能和一整套操縱流程，讓它也可以適應了商業軟件的開發。

Central and distribution

Git 和 SVN 代碼歷史的不同

SVN 的代碼歷史相對比較簡單，因爲它是中心化的，所有人的代碼都直接提交到某個 repository 上，所以它的 Reversion ID 號是一個按順序增加的數字類型，一般情況下不能在兩個數字之間插入別的 reversion。

SVN History

Git 的看起來就是雜亂多了，它的 Reversion ID 號是一個 40 位長度的 hash 值，通常也可以縮寫爲 7 位，這樣做的原因是因爲 Git 的最小單位是代碼修改的歷史，即爲補丁 Patch，而分支、 Tag、Remote（一會兒會說到這些概念）等都只是分支的集合，互相之間可以隨意拆分、合併。

我更願意把分支、Tag、Remote 想象成不同的平行宇宙，因爲某些機緣導致產生了分裂，走向了不同的歷史，也可能因爲某些機緣又合併到了一起，變得更加強大。

Git history

Git 基礎命令

Git sences

Git 按照場景可以分爲以下場景（Scence）：

1. Workspace：當前工作區，修改的的最初狀態。

2. Staging：修改後，添加到準備提交的緩存狀態。

3. Local repository：本地的代碼倉庫，只對自己的代碼生效。這也是和 svn 區別之一，svn commit 之後就直接提交到遠程服務器了，git commit 之後只是到本地代碼庫。

4. Remote repository：遠程代碼庫，將自己的本地代碼庫同步到遠程代碼庫上，這樣可以供別的開發者分享自己的成果。

具體流程看圖即可，下面對幾個常用命令進行簡單介紹

PS: 圖中沒有提到 rebase 和 cherry-pick 命令，這兩個命令也非常強大，後面有提到，有時間可以關注一下。

補丁 diff

之前有提到過，補丁是 Git/SVN 代碼版本管理的基礎概念，它其實是以行爲單位的文件修改歷史，增加行以 + 號開頭 ，刪除行以 - 號開頭，而修改一行，就是先 - 後 +。

在 Git 裏可以通過 git diff 或者 Linux/Mac/Conemu 中，也可以通過 diff -Naur 來生成文件對比結果，有點類似下圖。

這是整個代碼管理的基礎概念，所有的分支、Tag、Remote 都是在此基礎上衍生的。

Git diff

基本流程

1. 克隆代碼到本地開發環境 - Clone

$ git clone [REPOSITORY_URL]

對應到了 svn checkout 命令，用於把遠程代碼克隆到本地，跟 svn 一樣，REPOSITORY_URL 的協議非常靈活，之前流行用 ssh/scp 協議，但現在 https/http 協議漸漸流行起來了。

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

剛有提到過 Git 的四種場景，其中前兩種場景需要通過

$ git status

命令查看，代碼剛剛新建可以看到是 Untracked files（Workspace） 狀態，執行 add 之後變成 Changes to be commited（Stage） 狀態，修改了 Stage 中的文件，又會變成 Changes not staged for commit 狀態。執行 commit 之後就從 Stage 中轉移到了 Local repository 中，可以通過

$ git log

查看到代碼提交。

3. Branch 和 Tag

如剛從所說，Branch 和 Tag 都可以看成是補丁的時序化集合，branch 可以互相合並，在 clone 完 repository 後有一個主線分支叫做 master。而 Tag 用於發佈後標記版本，這兩個只是從名字上不一樣，功能（我感覺實現上）並沒有太大區別。

和 SVN 不同， SVN 的 Branch 和 Tag 都是把 Trunk 整個代碼庫拷貝出來，Git 只是將補丁引用重新對當前代碼應用一下，所以 Git 的 Branch/Tag 都非常輕量，切換起來非常輕鬆，使用 Git 要儘量多使用它的分支來提高開發效率，一會兒提到 Git flow 時會描述一下如果用分支進行代碼功能開發管理。

3.1 新建分支的兩種辦法

$ git checkout -b [BRANCH_NAME] # 在當前版本切換並新建分支
$ git branch [BRANCH_NAME] # 直接新建分支

3.2 切換分支

$ git checkout [BRANCH_NAME]

3.3 合併分支的兩種辦法

$ git merge [BRANCH_NAME] # 將另外一個分支的代碼，打到當前分支之後。
$ git rebase [BRANCH_NAME] # 不推薦，對代碼進行比較，將本分支修改後的代碼打到另外一個分支之後

rebase 通常情況下不推薦使用，因爲 rebase 完下游分支，再從上游分支 merge 的時候會丟失分支合併的 commit，但是對於部分有 history mysophobia 的人來說，它是保持代碼提交歷史記錄乾淨的神器，那個 Merge branch 'xxx' of http://git.code.oa.com/xxx into yyy 的 commit 看起來也挺討厭的。

對於已經推到 remote repository 的 commit，是不建議 rebase 的，因爲一旦 rebase 了，別人再 pull 就會出一大堆的衝突 conflict，而且基本沒法修，通常情況下還是建議用 merge 穩妥一些。

PS: rebase 還有一個強大的功能是配合 --interactive 參數修改之前的補丁，具體自己查一下，但是改完了 push --force 上去，別人再 pull 回來出 conflict 是必然的，但是這招是修改 Github 上的 Pull request（後面有提到）必備技能。

3.4 刪除分支

$ git branch -d [BRANCH_NAME] # 已經合併到 master
$ git branch -D [BRANCH_NAME] # 該分支未合併到 master，強制刪除

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

3.5 取消修改

git stash # 取消全部修改，很強大的是它可以恢復過來，具體自己查一下
git reset —soft [REV] # 保留修改內容，從 Local repository 中撤銷，也可以用於回退歷史記錄
git reset —hard [REV] # 丟掉修改內容，從 Local repository 中撤銷，也可以用於回退歷史記錄

推送本地代碼到遠程倉庫

推送代碼是爲了跟別人一起合作，命令行非常簡單

$ git push [REMOTE] [BRANCH]

remote 默認爲 origin，如果不填的話就推送到它上面，branch 默認爲當前分支，其實可以不加，加了就把指定的分支推送到遠程了。如果要將推送本地功能分支，建議 push 後面加上 —set-upstream 參數。

鄭重警告：永遠不要對主線 master 分支執行 —force

獲取遠程分支更新

$ git pull # 把代碼更新到  workspace
$ git fetch # 把代碼更新到 Local repository，可能需要通過 merge 再合併到 worksapce 一次。

遠程倉庫

Clone 之後會有一個默認的遠程倉庫爲 origin，但如果還要增加別的遠程倉庫，就需要用到下面命令了：

$ git remote add [REMOTE_NAME] [URL] # 添加原創倉庫
$ git fetch [REMOTE_NAME] # 獲取遠程倉庫更新
$ git branch -a # 查看包括遠程倉庫以內的所有分支
$ git push [REMOTE_NAME] [BRANCH_NAME] # 推送到遠程倉庫

Github Pull Request & Gitlab Merge Request

Github 在 Git Remote 的基礎上爲了方便大家參與開源項目，衍生出的一套機制，目前常規開源項目的參與流程是，先註冊一個 Github 賬號，然後將感興趣的開源項目 Fork 一份到自己的 namespace 下，然後拆分分支進行修改，然後提交到自己的 Github repository 下，再發起一個 Pull Request，讓項目維護者來合併你的代碼（Pull request 名副其實），在這個過程中，項目維護者會對你的代碼進行 Review 和點評，你得按照維護者要求進行修改（這裏 rebase 會用得很勤），修改通過，維護者同意後，就有他將代碼合併進項目中。

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

PS: 範例圖片在 PPT 的第 22 頁起

Git flow

Git flow 本來應該是本文的重點內容的，它是在 Git branch 的基礎上實現了一套簡單的功能模塊化開發流程，主要思想是把分支分成了上下游幾個層級，然後通過一套命令行工具進行維護。

1. master 分支 - 與線上版本保持一致，當發生線上問題後可以很輕鬆地修復。

2. develop 分支 - 功能開發基線分支，功能開發完之後合併到上面，所有功能開發完畢後經過測試上線，然後合併回 master。

3. feature/* 功能開發分支 - 從 develop 上拆分，也需要隨時把 develop 的更新 merge 回來，跟上游的分支保持一致，等功能開發完畢之後，即可合併到 develop。通過和上游分支保持一致，這樣可以避免對誤刪別人的代碼，所有代碼衝突必須在下游分支修好，測試完畢後纔可合併到上游分支。

4. hotfix/* 熱修復分支 - 主要用於線上 bug 修復，但是修復後應該同時合併到 master 和 develop 兩個分支上。

Git flow

然後 git flow 提供了套命令行工具來更加輕鬆地去做這些代碼合併的事情。

$ git flow init # 初始化 git flow 分支模型
$ git flow feature start [NAME] # 開始一個功能分支
$ git flow feature finish [NAME] # 將功能分支合併進 develop
$ git flow hotfix start [NAME] # 開始一個熱修復分支
$ git flow hotfix finish [NAME] # 將補丁合併進 develop 和 master
$ git flow release [NAME] # 發佈一個新版本，打 tag

感覺 Git flow 得有個篇幅，下次有機會再來詳述。

其它內容

有興趣可以繼續看一下別的相關內容，非常有意思：

1. git svn - Git 可以以 svn 爲代碼後端，通過 Giit 來對 SVN 裏的代碼進行版本管理。

2. git reflogs - 引用記錄，在 git 中誤刪除某提交是不用害怕的，只要 commit 了，就可以通過 reflogs 找到，用 reset 或者 cherry pick 恢復。

3. git cherry pick - 摘櫻桃（commit），從另一個分支中單獨將某個 patch 摘回來。

4. git bare repository - 建立 Git 服務器

5. git submodule - 子模塊，一個大項目可以通過 submodule 進行拆分，可以隨時進行子模塊的版本更新和回溯。

6. git hooks - 鉤子，當 git 在 repository 上發生某種行爲的時候，可以通過鉤子觸發一些行爲，像目前 Github 上的一些第三方持續集成服務，就是在此基礎上實現的。

7. git signature - 簽名，通過 gpg 在 commit 時對 patch 進行簽名，證明那個補丁確實是自己提交的，可以參考一下 Github 的文檔。

8. Source Tree - Source Tree 是一套跨平臺的 Git 圖形界面，簡單方便，我目前主要用它進行基本的 Patch 閱讀，比命令行更加舒服。

多謝閱讀，下次有機會再寫。

本文轉載自：「騰訊技術工程」，原文：https://tinyurl.com/35enxt8r，版權歸原作者所有。歡迎投稿，投稿郵箱: editor@hi-linux.com。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/9_0h4td25SeJU02C2Imyig