剛進公司，不懂GIt工作流的我瑟瑟發抖

前言

不懂git工作流，被辭退了！

之前在看到這句話的時候，我剛實習入職不久，瑟瑟發抖。好巧不巧，今天又看到了類似的文章講git重要性的。

眼下，學校導師安排給我的課題組了一個新的工程專案，使用gitee維護，因此我打算寫一篇文章總結一下git的工作流（git工作流就是指單人/多人團隊如何使用git命令配合維護一個專案的一些約定的流程，在確保有效迭代的同時，保持高效的協作方式），相信可以幫助那些使用git停留在單人維護遠端master分支的同學更進一步。

下面會講解四種git工作流，無論是在校課題組還是公司內部，都可以以此為基礎找到合適的git團隊工作模式。

Centralized Workflow 集中式工作流

介紹

三個開發人員共同維護一份遠端倉庫的程式碼，工作方式如下：

1. 每次工作前從remote拉取master分支到本地的master分支，然後處理衝突（使用IDE自帶的GUI圖形使用者介面處理衝突會比較方便，如圖中的goland內建的git工具）

   

2. 接著開始編碼，編碼完成後add修改的檔案到緩衝區

3. commit緩衝區檔案到自己local倉庫，並且push本地倉庫檔案到remote倉庫

評價

集中式工作流：這種工作方式簡單粗暴，所有人只使用master分支維護專案，master永遠是專案最新版本，編碼比較快，立竿見影。但是所有開發者提交日誌集中在一起呈單線延伸，難以定位問題，分工不明確，且容易發生衝突，處理衝突成本上升，但是單人開發很便利。

Feature Branch Workflow 功能分支工作流

介紹

功能分支工作流以集中式工作流為基礎，在維護master分支的基礎上，將專案的開發工作拆分為新增一個個的feature的形式，工作方式如下：

1. 一旦需要開發新的功能，就在remote的master分支的基礎上建立一個feature xxx分支

2. 本地建立對應的feature xxx分支

3. 每次開發前將remote庫的feature xxx分支拉取到本地，處理衝突

4. 然後在本地feature xxx分支上開發，然後push到remote的feature xxx分支

5. 在專案主頁上發起pull request（如果是gitlab則是merge request，作用相同），本意是提出將feature xxx分支合併入master分支的請求

   

6. 然後你的程式碼會被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工作流劃分分支更有約束性。主要包括：

1. 主分支master：用於跟蹤專案正式釋出的版本（tag標籤號）
2. 開發分支dev：用於跟蹤程式碼研發的提交歷史
3. 功能研發分支feature：每次有新的功能需要研發，以dev分支為基礎，建立feature分支，開發完成後按上面feature branch工作流的方式提交PR/MR到remote的dev分支，完成之後刪除對應feature分支
4. 熱修復分支hotfix：如上圖所示，master分支出現bug（線上報bug了），需要馬上從master拉取一個hotfix分支處理修復bug，並且將程式碼合併到master和dev（這兩個分支需要保持bug修復的一致性），修復後給master當前提交打一個tag（v0.2）
5. 釋出分支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工作流。

我是白澤，一個有點逗比的程式設計師/學生黨，我們們下期見。

歡迎大家關注公眾號【程式設計師白澤】。

剛建了個微信小群，歡迎一起交流學習，備戰秋招。