剛進公司，不懂GIt工作流的我瑟瑟發抖
前言
不懂git工作流，被辭退了！
之前在看到這句話的時候，我剛實習入職不久，瑟瑟發抖。好巧不巧，今天又看到了類似的文章講git重要性的。
眼下，學校導師安排給我的課題組了一個新的工程項目，使用gitee維護，因此我打算寫一篇文章總結一下git的工作流（git工作流就是指單人/多人團隊如何使用git命令配合維護一個項目的一些約定的流程，在確保有效迭代的同時，保持高效的協作方式），相信可以幫助那些使用git停留在單人維護遠程master分支的同學更進一步。
下面會講解四種git工作流中的前兩種，無論是在校課題組還是公司內部，都可以以此為基礎找到合適的git團隊工作模式。
Centralized Workflow 集中式工作流
介紹
三個開發人員共同維護一份遠程倉庫的代碼，工作方式如下：
-
每次工作前從
remote拉取master分支到本地的master分支，然後處理衝突（使用IDE自帶的GUI圖形用戶界面處理衝突會比較方便，如圖中的goland內置的git工具）
-
接着開始編碼，編碼完成後
add修改的文件到緩衝區 -
commit緩衝區文件到自己local倉庫，並且push本地倉庫文件到remote倉庫
評價
集中式工作流：這種工作方式簡單粗暴，所有人只使用master分支維護項目，master永遠是項目最新版本，編碼比較快，立竿見影。但是所有開發者提交日誌集中在一起呈單線延伸，難以定位問題，分工不明確，且容易發生衝突，處理衝突成本上升，但是單人開發很便利。
Feature Branch Workflow 功能分支工作流
介紹
功能分支工作流以集中式工作流為基礎，在維護master分支的基礎上，將項目的開發工作拆分為添加一個個的feature的形式，工作方式如下：
-
一旦需要開發新的功能，就在
remote的master分支的基礎上創建一個feature xxx分支 -
本地創建對應的
feature xxx分支 -
每次開發前將
remote庫的feature xxx分支拉取到本地，處理衝突 -
然後在本地
feature xxx分支上開發，然後push到remote的feature xxx分支 -
在項目主頁上發起
pull request（如果是gitlab則是merge request，作用相同），本意是提出將feature xxx分支合併入master分支的請求
-
然後你的代碼會被review，沒通過就本地改，改完之後繼續
push到remote（兩頭都在feature xxx分支），然後負責人繼續review你這個PR或者MR，通過之後會將feature xxx分支區別於master的改動合併入master，刪除remote的feature xxx分支，代表這個功能開發完畢
評價
功能分支工作流：這種工作方式帶來了code review的功能，使得推送的代碼更符合規範，減少bug產生。並且因為主要還是在master分支基礎上根據功能需求創建feature分支，使得開發工作十分靈活，且各個功能之間隔離，但是對於大型項目而言需要為不同分支分配更加具體的角色，只有feature分支是不夠的。
Gitflow Workflow
介紹
Gitflow工作流是我目前尚在熟悉的一種工作流，也是目前非常成熟的git工作流方案。區別於功能分支工作流，Gitflow工作流劃分分支更有約束性。主要包括：
- 主分支master：用於跟蹤項目正式發佈的版本（tag標籤號）
- 開發分支dev：用於跟蹤代碼研發的提交歷史
- 功能研發分支feature：每次有新的功能需要研發，以
dev分支為基礎，建立feature分支，開發完成後按上面feature branch工作流的方式提交PR/MR到remote的dev分支，完成之後刪除對應feature分支 - 熱修復分支hotfix：如上圖所示，
master分支出現bug（線上報bug了），需要馬上從master拉取一個hotfix分支處理修復bug，並且將代碼合併到master和dev（這兩個分支需要保持bug修復的一致性），修復後給master當前提交打一個tag（v0.2） - 發佈分支release：在
dev基礎上建立release分支，處理一些問題、修復一些bug之後，將代碼合併入master與dev，並給master打上tag（v1.0）表示發佈完成
評價
約束性更強，發佈迭代流程更規範，嚴謹，開發人員分工更明確，十分推薦學習使用。
Forking Workflow
介紹
這種工作流是開源項目維護的工作流，暫作了解即可，通過將他人的項目fork到自己的remote倉庫，就可以將其作為自己擁有的一份副本進行開發，比如想增加一個功能或者修復一個bug。這裡A與C都fork了B的倉庫，在各自開發完成新功能之後可以提交PR給B倉庫，B倉庫的開發者負責review代碼，並接受PR。
評價
具體還未嘗試過提交PR給開源項目，但是相信在掌握了上述三個git工作流之後，以後要使用到forking工作流的問題也應該引刃而解。
結束
學習了四種git工作流之後，並不是要完全照搬某一個模式的所有使用流程，而是應該結合實際的項目規模和人員規模進行合理安排。比如對於校內課題組較小的項目我認為feature branch工作流應該足以勝任，或者使用只有master、dev、feature的簡化版Gitflow工作流。
我是白澤，一個有點逗比的程序員/學生黨，咱們下期見。
歡迎大家關注公眾號【程序員白澤】。
剛建了個微信小群，歡迎一起交流學習，備戰秋招。
