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