Git，Git Flow，GitLab使用指南
高效利用一次蹲坑時間，看看如何使用Git Flow進行高效開發，什么才是Git提交的正確姿勢，怎樣使用GitLab進行Code Review：
使用Git Flow高效開發；
Git提交正確姿勢，Commit message編寫指南；
使用GitLab進行團隊內的Code Review；
使用Git Flow進行高效開發
在工作環境中，繞不開效率一詞，由于任何一次版本迭代，幾乎都是需要整個團隊協作的，所以，高效開發不僅僅是個人效率問題，還涉及到整個團隊的協作效率。個人開發，可以怎么順手怎么搞，怎么開心怎么玩，但在團隊里協作的時候，只一個人順手開心是不夠，還需要整個團隊協作高效。提高效率，一般我們會這么搞：
遵守行業內的最佳實踐；
借助工具自動遵循規范；
什么是Git Flow？
Git Flow是構建在Git之上的一個組織軟件開發活動的模型，是在Git之上構建的一項軟件開發最佳實踐。Git Flow是一套使用Git進行源代碼管理時的一套行為規范和簡化部分Git操作的工具，一篇名為A successful Git branching model的博文介紹了一種在Git之上的軟件開發模型。通過利用Git創建和管理分支的能力，為每個分支設定具有特定的含義名稱，并將軟件生命周期中的各類活動歸并到不同的分支上。實現了軟件開發過程不同操作的相互隔離。這種軟件開發的活動模型被稱為Git Flow。
Git Flow備忘清
Git Flow是一個Git擴展集，按Vincent Driessen的分支模型提供高層次的庫操作, 這個備忘清單展示了Git Flow的基本操作和效果。
Git Flow介紹
Git Flow常用的分支：master, develop, feature, hotfix, release;
歷史分支(master , develop): 相對使用僅有的一個master分支，Gitflow工作流使用2個分支來記錄項目的歷史。master分支存儲了正式發布的歷史，而develop分支作為功能的集成分支。 這樣也方便master分支上的所有提交分配一個版本號;
功能分支(Feature): 每個新功能位于一個自己的分支，這樣可以push到中央倉庫以備份和協作。 但功能分支不是從master分支上拉出新分支，而是使用develop分支作為父分支。當新功能完成時，合并回develop分支。 新功能提交應該從不直接與master分支交互;
發布分支(release): 一旦develop分支上有了做一次發布（或者說快到了既定的發布日）的足夠功能，就從develop分支上fork一個發布分支。 新建的分支用于開始發布循環，所以從這個時間點開始之后新的功能不能再加到這個分支上—— 這個分支只應該做Bug修復、文檔生成和其它面向發布任務。 一旦對外發布的工作都完成了，發布分支合并到master分支并分配一個版本號打好Tag。 另外，這些從新建發布分支以來的做的修改要合并回develop分支;
維護分支(hotfix): 維護分支或說是熱修復（hotfix）分支用于生成快速給產品發布版（production releases）打補丁，這是唯一可以直接從master分支fork出來的分支。 修復完成，修改應該馬上合并回master分支和develop分支（當前的發布分支）,master分支應該用新的版本號打好Tag。為Bug修復使用專門分支，讓團隊可以處理掉問題而不用打斷其它工作或是等待下一個發布循環。 你可以把維護分支想成是一個直接在master分支上處理的臨時發布;
借助工具自動遵循規范
Visual Studio有一個Git Flow插件GitFlow.VS, Sourcetree最新版本集成了Git Flow插件，這些插件的好處是最大化地簡化了命令，只有Start Feature、Finish Feature、Start Release、Finish Release、Start Hotfix、Finish Hotfix幾個操作，其他工作，Git Flow自動幫你完成：
新建功能分支：Git Flow會自動拉取最新的develop分支，然后自動從develop分支創建一個新的feature分支；
完成功能分支：Git Flow自動合并回develop分支，并默認刪除feature分支，可以更改默認行為；
新建發布分支：Git Flow會自動拉取最新的develop分支，然后自動從develop分支創建一個新的release分支；
完成發布分支：Git Flow自動合并回develop，master分支，如果提供tag名稱，則會自動在master打上Tag，并默認刪除feature分支，可以更改默認行為；
新建修復分支：Git Flow會自動拉取最新的或者指定Tag的master分支，然后自動從master分支創建一個新的hotfix分支；
完成修復分支：Git Flow自動合并回develop，master分支，如果提供tag名稱，則會自動在master打上Tag，并默認刪除hotfix分支，可以更改默認行為；
Visual Studio有一個Git Flow插件
通過Tools > Extensions and Updates > Online > Search gitflow 安裝Git Flow插件
裝好插件之后，Team Explorer會多一個GitFlow
點擊GitFlow后，如果是首次點擊，則會提示初始化操作
初始化之后，每次進入GitFlow，則會根據狀態提供創建或結束feature/release/hotfix分支
再次強調：?我們需要借助一個工具幫我們自動化遵循規范，比如GitFlow插件。
Git提交正確姿勢：Commit message編寫指南
Git 每次提交代碼，都要寫 Commit message（提交說明），否則就不允許提交，基本上，你寫什么都行，但是，一般來說，commit message 應該清晰明了，說明本次提交的目的。目前，社區有多種 Commit message 的寫法規范。本文介紹Angular規范，這是目前使用最廣的寫法，比較合理和系統化，并且有配套的工具。
Commit message 的作用
格式化的Commit message，有幾個好處。
提供更多的歷史信息，方便快速瀏覽；
可以過濾某些commit（比如文檔改動），便于快速查找信息；
可以直接從commit生成Change log；
Commit message 的格式
每次提交，Commit message 都包括三個部分：Header，Body 和 Footer。
<type>(<scope>): <subject>// 空一行<body>// 空一行<footer>其中，Header 是必需的，Body 和 Footer 可以省略。不管是哪一個部分，任何一行都不得超過72個字符（或100個字符）。這是為了避免自動換行影響美觀。
Header
Header部分只有一行，包括三個字段：type（必需）、scope（可選）和subject（必需）。
type用于說明 commit 的類別，只允許使用下面7個標識。
feat：新功能（feature）
fix：修補bug
docs：文檔（documentation）
style： 格式（不影響代碼運行的變動）
refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
test：增加測試
chore：構建過程或輔助工具的變動
scope用于說明 commit 影響的范圍，比如數據層、控制層、視圖層等等，視項目不同而不同。
subject是 commit 目的的簡短描述，不超過50個字符。
以動詞開頭，使用第一人稱現在時，比如change，而不是changed或changes
第一個字母小寫
結尾不加句號（.）
Body
Body 部分是對本次 commit 的詳細描述，可以分成多行, 有兩個注意點:
使用第一人稱現在時，比如使用change而不是changed或changes;
應該說明代碼變動的動機，以及與以前行為的對比;
Footer
Footer 部分只用于兩種情況:
如果當前代碼與上一個版本不兼容，則 Footer 部分以BREAKING CHANGE開頭，后面是對變動的描述、以及變動理由和遷移方法;
如果當前 commit 針對某個issue，那么可以在 Footer 部分關閉這個 issue (Closes #123, #245, #992), GitHub這個功能很好用；
Revert
還有一種特殊情況，如果當前 commit 用于撤銷以前的 commit，則必須以revert:開頭，后面跟著被撤銷 Commit 的 Header。
使用GitLab進行團隊內Code Review
Code Review的工具很多，Facebook非常有名的Phabricator已經開源。對于經常玩GitHub的人，應該很喜歡GitHub的PR功能，很多公司使用GitLab或者Gogs搭建自家的Git服務，GitLab的Merge Request功能同樣可以用于團隊內Code Review。
Branches Protection Setting
如果團隊內部需要強制進行Code Review, 那么擁有GitLab管理權限的開發人員，可以把Repo設置成只有develop和master分支，并把develop，master分支都保護起來，不允許任何開發人員直接push到這些分支，開發人員只能把Repo?FORK成自己的Repo。
Your project > Setting > Protected Branches
創建Merge Request
協作開發的同事，只能通過把Repo?FORK?成自己的Repo，之后從自己Repo clone到本地，然后使用Git Flow開發，一旦開發到一個需要Review的點，通過Merge Request向主Repo請求合并
Code Review
一旦Merge Request創建成功之后，主Repo擁有Code Review權限的人就會收到通知，Code Review的時候， 打開Open的Merge Request，會看到Commits， Changes，打開Changes，可以提交自己的Review建議，被Review的人繼續根據這些建議，在自己的Repo里修改，修改好之后提交，這時會在自己的Repo里及主Repo的Open?Merge Request里看到相應更改，因此可以繼續Review流程，直到Merge Request被合并，如下圖：
Syncing a FORK
因為團隊的Repo是多人協作開發的，也就是說，團隊的主Repo會被多個開發人員Fork，當每個協作開發的開發人員對團隊的主Repo請求Merge Request之后，負責進行Code Review的同事進行Review，完成代碼Review之后會合并到主Repo。這時，每個Fork的Repo需要同主Repo進行同步才能拿到最新代碼，具體操作步驟如下：
查看本地Repo是否設置了upstream；
D:\repos\Apollo>git remote -v origin ?http://git.code.oa.com/yingtingxu/Apollo.git (fetch) origin ?http://git.code.oa.com/yingtingxu/Apollo.git (push)如果沒有設置，則進行設置
D:\repos\Apollo>git remote add upstream http://git.code.oa.com/ACD/Apollo.gitD:\repos\Apollo>git remote -v origin ?http://git.code.oa.com/yingtingxu/Apollo.git (fetch) origin ?http://git.code.oa.com/yingtingxu/Apollo.git (push) upstream ? ? ? ?http://git.code.oa.com/ACD/Apollo.git (fetch) upstream ? ? ? ?http://git.code.oa.com/ACD/Apollo.git (push)獲取主Repo的更新
D:\repos\Apollo>git fetch upstream remote: Counting objects: 9, done remote: Finding sources: 100% (5/5) remote: Getting sizes: 100% (6/6) remote: Total 5 (delta 0), reused 5 (delta 0) Unpacking objects: 100% (5/5), done. From http://git.code.oa.com/ACD/Apollo* [new branch] ? ? ?develop ? ?-> upstream/develop* [new branch] ? ? ?master ? ? -> upstream/master合并更新，以合并develop為例
D:\repos\Apollo>git checkout developD:\repos\Apollo>git merge upstream/develop Updating e0d7ffe..2b7875f Fast-forwardversion.props | 2 +-1 file changed, 1 insertion(+), 1 deletion(-)原文地址：http://www.xyting.org/2017/02/19/git-flow-gitlab.html
.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注
總結
以上是生活随笔為你收集整理的Git，Git Flow，GitLab使用指南的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 老司机实战Windows Server
- 下一篇： 期待微软平台即服务技术Service F