上篇文章《說說git（一）》簡要的介紹了git的基本信息及要點，本篇主要說下git的工作流，git工作流是git倉庫的流程管理規范，它是項目協作的基礎，如果對它不了解，在需要多人共同完成的項目中，還是會捉襟見肘，相反，如果能夠在項目中實踐git工作流，會讓你有條不紊，事半功倍。
一般小團隊對代碼管理的重視程度不是很高，談到用git管理項目，他們往往只會停留在工具層面上，例如用SourceTree這樣的界面來下載、更新和上傳代碼，并沒有指定可持續發展的流程，這樣實際上帶來的問題很明顯，就是維護代碼的成本會比較高。
例如我曾經接手過一個這樣的項目，由于沒有很好的流程規范，以至于生產環境上的程序產生了bug，竟然不知道這個程序對應于代碼倉庫上的哪一次提交，進而在排查問題前，需要通過對比程序的部署日期和提交日期來確定，如果這一天有多次提交，還要先編譯不同的提交，并核實MD5值來確定，這種開發效率實在是低得可以。
制定git工作流的目的也是為了提高效率，使代碼倉庫的管理簡潔明了，讓開發者專注于業務的開發上，經過一段時間的實踐，我主要采用的是gitlab工作流來管理項目，下面分2點介紹一下：
- gitlab工作流
- bugfix如何處理
gitlab工作流
gitlab是一個非常優秀的開源軟件，對github比較了解的同學都知道，gitlab實際上是私有版的github，gitlab的工作流是建立在分支的基礎上的，在服務器開發的場景下，我們一般需要額外建立2個分支：pre-production分支和production分支，pre-production分支是預發布環境，主要用來模擬生產環境的測試，而production環境則是生產環境
有了這兩個分支，就可以制定提交的流程了，團隊里的每個人都按照這樣的流程來維護代碼，就不會出現混亂、難以管理等問題
- 創建一個issue，同時在issue頁面拉出一個分支
在上一篇里我說過，由于git的分支非常輕量，所以每個改動都可以新建一個分支，修改完成后再合并到主分支中去，那issue是什么呢，issue是這次修改的詳細描述，例如描述這次修改是一個新的功能，還是一個bug修復，這次修改的目的是什么，如何完成這次修改。同時它可以關聯一個分支，最終這個分支的提交、合并等整個過程都可以由這個issue來追蹤。
創建issue
在issue下創建分支
分支創建好后，可以在終端執行git fetch origin master把新創建的分支拉到本地，這樣就可以在本地通過新的分支開發新功能了。
這里需要注意的是，一個issue的開發周期不宜過長，最好控制在1天，否則跨了多天的提交，最后合并起來會帶來很大的麻煩。
- 提交代碼
開發完成后，就可以把代碼提交到對應的遠程分支上了，如果你設置了gitlab CI，提交后還會觸發對代碼的編譯、測試等步驟，這取決于你的CI的具體設置，目的也是為了保證你的提交質量。關于CI，這里就不多講了，有機會我再寫一篇相關的文章。 - code review
提交代碼后，我們需要讓團隊里的其他小伙伴對代碼進行review，code review的好處很多，除了可以幫助統一團隊的編碼格式之外，還可以幫助檢查一些顯而易見的錯誤，最大的好處是提升了團隊對業務的理解水平，而不是各自負責一個模塊，形成了孤島。gitlab提供了很好的code review功能，它不僅會對代碼修改點進行區別的顯示，同時還可以在代碼上進行注釋，這些注釋，開發者需要逐個solve掉，否則被認為是不能合并到主分支上。 - 合并代碼
通過了層層的審核，最后終于可以合并到主分支上了，當然這一步可以和第3步一起完成，即先創建Merge Request，然后項目管理者在合并代碼前，先進行code review，通過后再允許合并到主分支上。
以上便是日常開發代碼的基本流程，可以涵蓋了開發工作中涉及git操作的80%的內容，剩下20%在哪里？你就要了解后面的內容了
bugfix如何處理
bugfix主要是修復生產環境中發現的bug，找到解決思路后，我們一般需要以下步驟去完成這個任務：
- 找到生產環境上對應的具體commit_id
- 創建bugfix類型的issue和分支，并回退到第1步的那個commit
- 修改代碼，打補丁
- 測試
- 將補丁合并到master分支上
- 用修改后的程序替換掉生產環境上的程序
以上步驟中，如果沒有很好的工作流，第1步和第6步是比較難操作的，第1步上文已經說過了，第6步為什么難操作呢，因為它需要手動將修改后的代碼與master分支的代碼對比后，合并到master上，為什么要手動呢，因為git是不允許從一個舊的提交向較新的提交上合并的，你可能會問：能不能不這么原始呢，因為手動對比真的是很費時。答案是有的，有個概念叫cherry-pick，可以完成這樣的功能，但問題就在這里了，這個概念大多數人平時是沒有接觸過的，而且即便看過書，也很難理解它到底有什么用，即把它應用到工作中的概率極低。
使用gitlab工作流后，可以很好的改善以上的窘境，因為每次你合并代碼，都會有個大大的cherry-pick按鈕彈出來，好奇心的驅使，會讓你遲早知道這功能是怎么回事兒。說了不少廢話，下面說下gitlab工作流怎么完成bugfix的流程。
還記得之前我們創建的3個分支嗎，其中production分支里的所有提交，都對應于生產環境中的一個版本，那么以上的第1步就很好解決了，很快便可以找到生產環境上的版本對應的那個commit_id。下面還需要修改下第5步的內容：
- 將代碼合并到production分支，合并完成后，cherry-pick到master分支上
下面三個截圖是整個合并過程
打補丁，合并到production分支（截圖是release分支，是一回事），注意這里不要勾選Remove source branch選項，勾選了就無法進行cherry-pick了
合并成功會彈出Cherry-pick對話框
將補丁Cherry-pick到master分支上
以上便是開發工作中，幾乎可以全部覆蓋的涉及到git的工作流程，遵守這一套流程，可以讓我們的開發協作更為高效，下一篇，我會介紹一下CI和git如何結合，及如何進行開發過程中的版本管理。
