一文读懂Git工作流
Git是目前最流行的代碼管理工具，相信大家也都是在用Git來管理自己團隊的源代碼。
團隊一般為了規范開發，保持良好的代碼提交記錄以及維護 Git 分支結構清晰，方便后續維護等，都會迫切需要一個比較規范的 Git 工作流。
本文就是在這個背景下誕生的，如果你的團隊正好有此需求，那你可以看一下，希望本文能給大家提供一些幫助，建立良好的團隊代碼流程規范。
本文的目錄如下
- Git主要優點
- Git分支管理
- Git日志規范
- Git Flow工作流
- Git Flow實戰
Git主要優點
- 分布式存儲，本地倉庫包含了遠程倉庫的所有內容。
- 安全性高，遠程倉庫文件丟失了也不怕。
- 優秀的分支模型，創建/合并分支都非常快速便捷。
Git分支管理
我們在實際工作中會創建很多分支以便于不同場景下的開發，但是如果沒有分支規范就會造成分支雜亂，大家往往也搞不清楚某一個分支是在做什么，下面我們就介紹一下我們常用的并且推薦大家使用的分支類型。
Git分支類型
master 分支
- master 為產品主分支，該分支為只讀唯一分支，也是用于部署生產環境的分支，需確保master分支的穩定性。
- master 分支一般由release分支或hotfix分支合并，任何情況下都不應該直接修改master分支代碼。
- 產品的功能全部實現后，最終在master分支對外發布，另外所有在master分支的推送應該打標簽（tag）做記錄，方便追溯。
- master 分支不可刪除。
develop 分支
- develop 為主開發分支，基于master分支創建，始終保持最新完成功能的代碼以及bug修復后的代碼。
- develop 分支為只讀唯一分支，只能從其他分支合并，不可以直接在該分支做功能開發或bug修復。
- 一般開發新功能時，feature分支都是基于develop分支下創建的。
- develop 分支包含所有要發布到下一個release的代碼。
- feature功能分支完成后, 開發人員需合并到develop分支(不推送遠程)，需先將develop分支合并到feature，解決完沖突后再合并到develop分支。
- 當所有新功能開發完成后，開發人員并自測完成后，此時從develop拉取release分支，進行提測。
- release或hotfix 分支上線完成后, 開發人員需合并到develop分支并推送遠程。
- develop 分支不可刪。
feature 分支
- feature 分支通常為新功能或新特性開發分支，以develop分支為基礎創建feature分支。
- 分支命名: feature/ 開頭的為新特性或新功能分支，建議的命名規則: feature/user_createtime_feature，例如：feature/ftd_20201018_alipay，含義為：開發人員ftd在2020年10月18日時創建了一個支付寶支付的功能分支。
- 新特性或新功能開發完成后，開發人員需合到develop分支。
- feature 分支可同時存在多個，用于團隊中多個功能同時開發。
- feature 分支屬于臨時分支，功能完成后可選刪除。
release 分支
- release 分支為預上線分支，基于本次上線所有的feature分支合并到develop分支之后，從develop分支創建。
- 分支命名: release/ 開頭的為預上線分支，建議的命名規則: release/version_publishtime，例如：release/v2.1.1_20201018，含義為：版本號v2.1.1計劃于2020年10月18日時發布。
- release 分支主要用于提交給測試人員進行功能測試。發布提測階段，會以release分支代碼為基準進行提測。測試過程中發現的bug在本分支進行修復，上線完成后需合并到develop/master分支并推送遠程。
- release 分支屬于臨時分支，產品上線后可選刪除。
當有一組feature開發完成后，首先開發人員會各自將最新功能代碼合并到develop分支。進入提測階段時，開發組長在develop分支上創建release分支。
如果在測試過程中發現bug需要修復，則直接由開發者在release分支修復并提交。當測試完成后，開發組長將release分支合并到master和develop分支，此時master為最新可發布代碼，用作產品發布上線。
hotfix 分支
- hotfix 分支為線上bug修復分支或叫補丁分支，主要用于對線上的版本進行bug修復。
- 分支命名: hotfix/ 開頭的為修復分支，它的命名規則與 feature 分支類似，建議的命名規則: hotfix/user_createtime_hotfix，例如：hotfix/ftd_20201018_alipaybugfix，含義為：開發人員ftd在2020年10月18日時創建了一個支付寶支付bug修復的分支。
- hotfix 分支用于線上出現緊急問題時，需要及時修復，以master分支為基線，創建hotfix分支。當問題修復完成后，需要合并到master分支和develop分支并推送遠程。
- 所有hotfix分支的修改會進入到下一個release。
- hotfix 分支屬于臨時分支，bug修復上線后可選刪除。
以上就是在工作中常用到的6種分支類型，覆蓋了開發中的常見場景，大家也可以根據實際工作情況進行調整，重點是讓團隊小伙伴都能對整個分支的類型及作用了解即可。
分支創建好了，小伙伴們也都開始按照流程開始開發了，但是在日常開發中由于缺少對于commit message的約束，導致填寫內容隨意、質量參差不齊，可讀性低亦難以維護。在項目中引入commit message規范已是迫在眉睫。書寫良好的commit message能大大提高代碼維護的效率。
Git日志規范
在一個團隊協作的項目中，開發人員需要經常提交一些代碼去修復bug或者實現新的feature。而項目中的文件和實現什么功能、解決什么問題都會漸漸淡忘，最后需要浪費時間去閱讀代碼。但是好的日志規范commit messages編寫有幫助到我們，它也反映了一個開發人員是否是良好的協作者。
編寫良好的Commit messages可以達到3個重要的目的：
- 加快代碼view的流程
- 幫助開發人員編寫良好的版本發布日志
- 讓之后的維護者了解代碼里出現特定變化和feature被添加的原因
目前，社區有多種 Commit message 的寫法規范。來自Angular 規范是目前使用最廣的寫法，比較合理和系統化。建議使用如下：
Commit messages的基本語法
具體格式為:
# EN <type>(<scope>): <subject> <BLANK LINE> <body> <BLANK LINE> <footer># CN <類型>[可選的作用域]: <描述>[可選的正文][可選的腳注]- type: 本次 commit 的類型，諸如 bugfix、docs、style 等，類型說明參見下方。
- scope: 本次 commit 影響的范圍，比如數據層、控制層、視圖層等等，視項目不同而不同。
- subject: 簡明扼要的闡述下本次 commit 的主旨，是 commit 目的的簡短描述，建議不超過50個字符。
- body: 在主體內容中我們需要把本次 commit 詳細的描述一下，比如此次變更的動機，詳細的修改方法或其他需要額外重點說明的內容。
- footer: 描述下與之關聯的 issue 或 break change，詳見案例。
Type的類別說明：
# 主要type feat: 增加新功能 fix: 修復bug# 特殊type docs: 只改動了文檔相關的內容 style: 不影響代碼含義的改動，例如去掉空格、改變縮進、增刪分號 build: 構造工具的或者外部依賴的改動，例如webpack，npm refactor: 代碼重構時使用 revert: 執行git revert打印的message# 暫不使用type test: 添加測試或者修改現有測試 perf: 提高性能的改動 ci: 與CI（持續集成服務）有關的改動 chore: 不修改src或者test的其余修改，例如構建過程或輔助工具的變動Commit messages格式要求
# 標題行：50個字符以內，描述主要變更內容 # # 主體內容：更詳細的說明文本，建議72個字符以內。 需要描述的信息包括: # # * 為什么這個變更是必須的? 它可能是用來修復一個bug，增加一個feature，提升性能、可靠性、穩定性等等 # * 如何解決這個問題? 具體描述解決問題的步驟 # * 是否存在副作用、風險? # # 如果需要的話可以添加一個鏈接到issue地址或者其它文檔示例：
# fix：修復支付寶支付bug # # 1，修復支付完成后未查詢支付狀態問題 # 2，增加定時任務保證支付狀態完整 # # link：http://github.com/ftd/shopmall/issue001注：如果一次改動內容較多，包含多個提交類型時，建議拆分成多個提交，分次提交，這樣會更清晰。
Git Flow工作流
我們現在已經了解了Git的分支，包括分支有哪些類型，什么情況下使用什么類型的分支，以及提交的格式規范等。不過往往在一個團隊人數較多，創建的分支也比較多的時候，還是會帶來很多分支操作上的困擾。那有沒有一個什么好的流程來規范大家呢，針對這些問題，建議大家使用Git Flow的工作流模式。
Git Flow 流程圖
1，主分支流程
- master分支記錄了每次版本發布歷史和tag標記。
- develop分支記錄了所有開發的版本歷史。
- develop分支僅第一次創建時從master分支拉取。
2，開發流程
- feature分支是從develop分支拉取的分支。
- 每個feature完成后需合并到develop分支。
3，提測發布流程
- release分支是在所有功能開發自測完成后，從develop分支拉取的分支。
- release分支一旦創建后，通常不再從develop分支拉取，該分支只做bug修復，文檔生成和其他面向發布的任務。
- release分支測試完成，達到上線標準后，需合并回master分支和develop分支。
4，bug修復流程
- hotfix分支是在線上出現bug之后，從master分支拉取的分支。
- hotfix分支測試完成后，需合并回master分支和develop分支。
Git Flow實戰
Git Flow的流程搞清楚后，我們下面開始實際的項目實戰，假設我們現在有一個商城的項目，并且我們已經建好了Git倉庫。
我們通過命令行和圖形界面的方式分別向大家展示如何使用Git Flow工作流。
Git Flow 命令示例
開始 Feature
# 創建feature分支 git flow feature start ftd_20201018_wechatpay# 指定當前分支pull的源為develop git branch --set-upstream-to=origin/develop feature/ftd_20201018_wechatpay完成 Feature
# 發布feature git flow feature publish ftd_20201018_wechatpay# 完成feature git flow feature finish ftd_20201018_wechatpay開始 Release
git flow release start v1.0_20201031完成 Release
git flow release finish v1.0_20201031開始 Hotfix
git flow hotfix start ftd_20201031_bugfix完成 Hotfix
git flow hotfix finish ftd_20201031_bugfix大家可以看到，簡簡單單幾行命令就可以完成比較復雜的流程管理，如果對于命令行不太擅長的小伙伴還可以使用圖形工具，這里推薦使用sourcetree，sourcetree也是著名的Git管理工具，可以大大方便我們對Git的操作和使用，下面就來介紹一下sourcetree中如何使用Git Flow。
注：以下內容為Windows版本的sourcetree為例，Mac類似。
初始化GitFlow
打開sourcetree，選擇想使用Git Flow工作流的項目，在右上角點擊Git工作流按鈕，如下圖所示：
隨后會彈出對話框，可以選擇產品分支，開發分支以及功能分支等，如下圖所示：
點擊確定后完成倉庫的Git Flow初始化。
開始 Feature
點擊右上角Git工作流，顯示如圖界面：
輸入本次功能的名稱，點擊確定創建feature分支
可以看到本地已經有了新建的feature分支，如圖所示：
然后就可以在該分支進行功能開發了。
完成 Feature
功能開發完成之后，還是點擊右上角Git工作流，顯示如圖界面：
點擊完成功能，如下圖所示：
這里可以選擇將該feature分支刪除或保留，可以根據團隊的規定來處理即可。
點擊確定后，完成feature功能的開發。
至此該流程處理完畢。
開始 Release
同樣的，點擊右上角Git工作流，選擇建立新的發布版本，顯示如下：
輸入發布版本名稱，點擊確定，完成release分支的創建。
此時可以看到已經創建的release分支，如下圖所示：
完成 Release
測試通過后，可以進行release版本的發布，如下圖所示：
輸入該發布的標簽信息，點擊確定進行發布。
至此，我們已經完成了release的發布流程。
Hotfix
hotfix流程與上述流程操作方法類似，再次不再贅述，大家可以通過軟件進行操作練習。
結語
好了，到這里，我們關于Git工作流的內容已經全部講完啦，大家可以根據自己團隊的需要進行使用和改進，以讓團隊的協作更加高效和規范。
如果你喜歡本文,
掃描二維碼，關注「我是開發者FTD」公眾號
關注開發，更關注開發者！
總結
以上是生活随笔為你收集整理的一文读懂Git工作流的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： GTank iOS App Techni
- 下一篇： STM32基于SPI和AD7192的数据