Git常用概念
倉庫（Repositories）：類似我們生活中的倉庫，存儲東西，在這是網絡或者本地實際存放代碼的地方，同一個倉庫可存多個項目。
參照（References）：可以看做是指向文件塊中特定代碼版本的指針，可沿代碼版本有向圖進行向前（一般指提交操作Commit）,向後（一般是恢復操作Restore）, 跳轉（不同分支間的切換Switch）。
分支（Branch）：一般是爲了進行代碼調試或概念開發，從主要的開發版本中分離出一個副版本，並在此基礎上進行修改，（實際中我們可以分離出來進行各自的模塊開發）使版本有向圖呈現分支狀態。
合併(Merge)： 一般是爲了將代碼調試或概念開發分支的代碼加入到主要版本中，將對兩部分的代碼進行比較：
a) 先向後回朔兩個分支的最近公共節點，通過與最近的公共節點進行比較，分析兩個分支各對哪些文件進行了修改（因爲是文件塊，所以需要對兩個版本的文件求差，傳統模式則需要對兩個版本的記錄進行求和）
b) 合併最容易產生的錯誤（衝突）如果某一個文件在 兩個版本中均被修改過，則視爲“衝突”，這時我們解決的辦法是需要人工手動調整其中一個版本，這裏推薦使用一個工具（BCompare）可以快速明瞭的看出修改的地方； 否則，即自動將兩個版本分別修改後的部分，未修改的部分合併成一個新的版本。
標籤（Tag）：不移動的參照（指針），以標記特殊的代碼版本副本，比如說項目的里程碑等
Git使用流程
- 新建分支
首先，每次開發新功能，都應該新建一個單獨的分支
#獲取主幹最新代碼
$ git checkout master
$ git pull
#新建一個開發分支myfeature
$ git checkout -b myfeature
- 提交分支commit
分支修改後，就可以提交commit了。
git add 命令的all參數，表示保存所有變化（包括新建、修改和刪除）。從Git 2.0開始，all是 git add 的默認參數，所以也可以用 git add . 代替。
git status 命令，用來查看發生變動的文件。
git commit -m “some message” 撰寫提交信息提交commit時，必須給出完整扼要的提交信息，羅列出改動原因、主要變動、以及需要注意的問題
$ git add --all
$ git status
$ git commit -m "some message"
- 與主幹同步
分支的開發過程中，要經常與主幹保持同步。
$ git fetch origin
$ git rebase origin/master
- 合併commit
分支開發完成後，很可能有一堆commit，但是合併到主幹的時候，往往希望只有一個（或最多兩三個）commit，這樣不僅清晰，也容易管理。
那麼，怎樣才能將多個commit合併呢？這就要用到 git rebase 命令。rebase：一般翻譯爲「衍合」或「變基」
使用 rebase 需要遵循一條準則：
一旦分支中的提交對象發佈到公共倉庫，就千萬不要對該分支進行衍合操作。
簡單來說，當待合併 commit 記錄中雜糅着他人的 commit 記錄，此時就不可以再對這部分 commit 記錄做合併操作。
但只要新開分支且保持分支獨立開發，雜糅的情況就不存在。
$ git rebase -i origin/master
- 推送到遠程倉庫】
合併commit後，就可以推送當前分支到遠程倉庫了
$ git push origin myfeature
$ git push --force origin myfeature //rebase以後，分支歷史改變了，跟遠程分支不一定兼容，有可能要強行推送,但是這個操作要謹慎
- 發出Pull Request
提交到遠程倉庫以後，就可以發出 Pull Request 到master分支，然後請求別人進行代碼review，確認可以合併到master。
當完成功能後提交到遠程後，需要經過下述流程：
1 提交 Merge Request：通過「＋Create Merge Request」按鈕創建一個 Merge Request；
2 必須指定「Assignee」：指定需要 review 你代碼的同學，禁止指定自己；
3 更改「Target branch」：改變爲需要合併進去的目標分支；
4 設置合併後刪除被合併分支的選項：勾選「Remove source branch when merge request is accepted.」選項，在合併完成後刪除源分支，控制分支總數量，使用「Submit Merge Request」提交合並請求；
5 完成上述設置後，相關同學將會收到郵件通知，此時可進入 GitLab 進行 code review。
如果發現問題則對問題代碼進行點評並拒絕關閉申請，反之則通過合併申請。
合併申請通過後留下的 Merge Request 記錄，也就記錄了 code reviewer 。
項目中長期存在的兩個分支
master：主分支，負責記錄上線版本的迭代，該分支代碼與線上代碼是完全一致的。
develop：開發分支，該分支記錄相對穩定的版本，所有的feature分支和bugfix分支都從該分支創建。
短期分支（其完成功能開發之後需要刪除）
feature/：特性（功能）分支，用於開發新的功能（幾乎可以認爲是開發和對應測試人員的私人分支, 基本上就是單分支模式的開發模型），不同的功能創建不同的功能分支，功能分支開發完成並自測通過之後，需要合併到 develop 分支，之後刪除該分支。
bugfix/：bug修復分支，用於修復不緊急的bug，普通bug均需要創建bugfix分支開發，開發完成自測沒問題後合併到 develop 分支後，刪除該分支。
release/：發佈分支，用於代碼上線準備，該分支從develop分支創建，創建之後由測試同學發佈到測試環境進行測試，測試過程中發現bug需要開發人員在該release分支上進行bug修復，所有bug修復完後，在上線之前，需要合併該release分支到master分支和develop分支。
hotfix/：緊急bug修復分支，該分支只有在緊急情況下使用，從master分支創建，用於緊急修復線上bug，修復完成後，需要合併該分支到master分支以便上線，同時需要再合併到develop分支。
Code Review有什麼好處？
團隊知識共享的角度
一個開發團隊中，水平有高有低，每個人側重的領域也有不同。怎麼讓高水平的幫助新人成長？怎麼讓大家都對自己側重領域之外的知識保持瞭解？怎麼能有人離職後其他人能快速接手？這些都是團隊管理者關心的問題。而代碼審查，就是一個很好的知識共享的方式。通過代碼審查，高手可以直接指出新手代碼中的問題，新手可以馬上從高手的反饋中學習到好的實踐，得到更快的成長；通過代碼審查，前端也可以去學習後端的代碼，做功能模塊A的可以去了解功能模塊B的。
可能有些高手覺得給新手代碼審查浪費時間，自己也沒收穫。其實不然，新人成長了，就可以更多的幫高手分擔繁重的任務；代碼審查中花時間，就少一些幫新人填坑擦屁股的時間；良好的溝通能力、發現問題的能力、幫助其他人成長，都是技術轉管理或技術上更上一層樓必不可少的能力，而通過代碼審查可以有效的去練習這些方面的能力。
代碼質量的角度
現實中的項目總是人手缺進度緊，所以被壓縮的往往就是自動化測試和代碼審查，結果影響代碼質量，欠下技術債務，最後還是要加倍償還。
也有人寄希望於開發後的人工測試，然而對於代碼質量來說，很多問題通過測試是測試不出來的，只能通過代碼審查。比如說代碼的可讀性可維護性，比如代碼的結構，比如一些特定條件才觸發的死循環、邏輯算法錯誤，還有一些安全上的漏洞也更容易通過代碼審查發現和預防。
也有人覺得自己水平高就不需要代碼審查了。對於高手來說，讓別人審查自己的代碼，可以讓其他人學習到好的實踐；在讓其他人審查的同時，在給別人說明自己代碼的時候，也等於自己對自己的代碼進行了一次審查。這其實就跟我們上學時做數學題一樣，真正能拿高分的往往是那些做完後還會認真檢查的。
團隊規範的角度
每個團隊都有自己的代碼規範，有自己的基於架構設計的開發規範，然而時間一長，就會發現代碼中出現很多不遵守代碼規範的情況，有很多繞過架構設計的代碼。比如難以理解和不規範的命名，比如三層架構裏面UI層繞過業務邏輯層直接調用數據訪問層代碼。
如果這些違反規範的代碼被糾正的晚了，後面再要修改就成本很高了，而且團隊的規範也會慢慢的形同虛設。
Code Review清單
常規項
代碼能夠工作麼？它有沒有實現預期的功能，邏輯是否正確等。
所有的代碼是否簡單易懂？
代碼符合你所遵循的編程規範麼？這通常包括大括號的位置，變量名和函數名，行的長度，縮進，格式和註釋。
是否存在多餘的或是重複的代碼？
代碼是否儘可能的模塊化了？
是否有可以被替換的全局變量？
是否有被註釋掉的代碼？
循環是否設置了長度和正確的終止條件？
是否有可以被庫函數替代的代碼？
是否有可以刪除的日誌或調試代碼？
安全
所有的數據輸入是否都進行了檢查（檢測正確的類型，長度，格式和範圍）並且進行了編碼？
在哪裏使用了第三方工具，返回的錯誤是否被捕獲？
輸出的值是否進行了檢查並且編碼？
無效的參數值是否能夠處理？
文檔
是否有註釋，並且描述了代碼的意圖？
所有的函數都有註釋嗎？
對非常規行爲和邊界情況處理是否有描述？
第三方庫的使用和函數是否有文檔？
數據結構和計量單位是否進行了解釋？
是否有未完成的代碼？如果是的話，是不是應該移除，或者用合適的標記進行標記比如‘TODO’？
測試
代碼是否可以測試？比如，不要添加太多的或是隱藏的依賴關係，不能夠初始化對象，測試框架可以使用方法等。
是否存在測試，它們是否可以被理解？比如，至少達到你滿意的代碼覆蓋(code coverage)。
單元測試是否真正的測試了代碼是否可以完成預期的功能？
是否檢查了數組的“越界“錯誤？
是否有可以被已經存在的API所替代的測試代碼？
參考
https://juejin.im/post/59e5b683f265da432c22ec89
http://www.ruanyifeng.com/blog/2015/08/git-use-process.html
https://www.cnblogs.com/kuangliu/p/10942273.html