Git 全功能介紹
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）：
- Workspace：當前工作區，修改的的最初狀態。
- Staging：修改后，添加到準備提交的緩存狀態。
- Local repository：本地的代碼倉庫，只對自己的代碼生效。這也是和 svn 區別之一，svn commit 之后就直接提交到遠程服務器了，git commit 之后只是到本地代碼庫。
- 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 的基礎上實現了一套簡單的功能模塊化開發流程，主要思想是把分支分成了上下游幾個層級，然后通過一套命令行工具進行維護。
- master 分支 - 與線上版本保持一致，當發生線上問題后可以很輕松地修復。
- develop 分支 - 功能開發基線分支，功能開發完之后合并到上面，所有功能開發完畢后經過測試上線，然后合并回 master。
- feature/* 功能開發分支 - 從 develop 上拆分，也需要隨時把 develop 的更新 merge 回來，跟上游的分支保持一致，等功能開發完畢之后，即可合并到 develop。通過和上游分支保持一致，這樣可以避免對誤刪別人的代碼，所有代碼沖突必須在下游分支修好，測試完畢后才可合并到上游分支。
- 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 得有個篇幅，下次有機會再來詳述。
其它內容
有興趣可以繼續看一下別的相關內容，非常有意思：
- git svn - Git 可以以 svn 為代碼后端，通過 Giit 來對 SVN 里的代碼進行版本管理。
- git reflogs - 引用記錄，在 git 中誤刪除某提交是不用害怕的，只要 commit 了，就可以通過 reflogs 找到，用 reset 或者 cherry pick 恢復。
- git cherry pick - 摘櫻桃（commit），從另一個分支中單獨將某個 patch 摘回來。
- git bare repository - 建立 Git 服務器
- git submodule - 子模塊，一個大項目可以通過 submodule 進行拆分，可以隨時進行子模塊的版本更新和回溯。
- git hooks - 鉤子，當 git 在 repository 上發生某種行為的時候，可以通過鉤子觸發一些行為，像目前 Github 上的一些第三方持續集成服務，就是在此基礎上實現的。
- git signature - 簽名，通過 gpg 在 commit 時對 patch 進行簽名，證明那個補丁確實是自己提交的，可以參考一下 Github 的文檔。
- Source Tree - Source Tree 是一套跨平臺的 Git 圖形界面，簡單方便，我目前主要用它進行基本的 Patch 閱讀，比命令行更加舒服。
