來源|?juejin.im/post/6844903635533594632

Git 是目前最流行的源代碼管理工具。為規范開發，保持代碼提交記錄以及 git 分支結構清晰，方便后續維護，現規范git的相關操作。

分支命名

1、master 分支

master 為主分支，也是用于部署生產環境的分支，確保master分支穩定性， master 分支一般由develop以及hotfix分支合并，任何時間都不能直接修改代碼

2、develop 分支

develop 為開發分支，始終保持最新完成以及bug修復后的代碼，一般開發的新功能時，feature分支都是基于develop分支下創建的。

feature 分支

• 開發新功能時，以develop為基礎創建feature分支。
• 分支命名: feature/ 開頭的為特性分支， 命名規則: feature/user_module、 feature/cart_module

release分支

release 為預上線分支，發布提測階段，會release分支代碼為基準提測。當有一組feature開發完成，首先會合并到develop分支，進入提測時會創建release分支。如果測試過程中若存在bug需要修復，則直接由開發者在release分支修復并提交。當測試完成之后，合并release分支到master和develop分支，此時master為最新代碼，用作上線。

hotfix 分支

分支命名: hotfix/ 開頭的為修復分支，它的命名規則與feature分支類似。線上出現緊急問題時，需要及時修復，以master分支為基線，創建hotfix分支，修復完成后，需要合并到master分支和develop分支

常見任務

增加新功能

(dev)$:?git?checkout?-b?feature/xxx????????????#?從dev建立特性分支
(feature/xxx)$:?blabla?????????????????????????#?開發
(feature/xxx)$:?git?add?xxx
(feature/xxx)$:?git?commit?-m?'commit?comment'
(dev)$:?git?merge?feature/xxx?--no-ff??????????#?把特性分支合并到dev

修復緊急bug

(master)$:?git?checkout?-b?hotfix/xxx?????????#?從master建立hotfix分支
(hotfix/xxx)$:?blabla?????????????????????????#?開發
(hotfix/xxx)$:?git?add?xxx
(hotfix/xxx)$:?git?commit?-m?'commit?comment'
(master)$:?git?merge?hotfix/xxx?--no-ff???????#?把hotfix分支合并到master，并上線到生產環境
(dev)$:?git?merge?hotfix/xxx?--no-ff??????????#?把hotfix分支合并到dev，同步代碼

測試環境代碼

(release)$:?git?merge?dev?--no-ff?????????????#?把dev分支合并到release，然后在測試環境拉取并測試

生產環境上線

(master)$:?git?merge?release?--no-ff??????????#?把release測試好的代碼合并到master，運維人員操作
(master)$:?git?tag?-a?v0.1?-m?'部署包版本名'??#給版本命名，打Tag

日志規范

在一個團隊協作的項目中，開發人員需要經常提交一些代碼去修復bug或者實現新的feature。

而項目中的文件和實現什么功能、解決什么問題都會漸漸淡忘，最后需要浪費時間去閱讀代碼。但是好的日志規范commit messages編寫有幫助到我們，它也反映了一個開發人員是否是良好的協作者。

編寫良好的Commit messages可以達到3個重要的目的：

• 加快review的流程
• 幫助我們編寫良好的版本發布日志
• 讓之后的維護者了解代碼里出現特定變化和feature被添加的原因

目前，社區有多種 Commit message 的寫法規范。來自Angular 規范是目前使用最廣的寫法，比較合理和系統化。如下圖：

Commit messages的基本語法

當前業界應用的比較廣泛的是 Angular Git Commit Guidelines

“https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines

具體格式為:

<type>:?

• type: 本次 commit 的類型，諸如 bugfix docs style 等
• scope: 本次 commit 波及的范圍
• subject: 簡明扼要的闡述下本次 commit 的主旨，在原文中特意強調了幾點：
  • 使用祈使句，是不是很熟悉又陌生的一個詞
  • 首字母不要大寫
  • 結尾無需添加標點

body: 同樣使用祈使句，在主體內容中我們需要把本次 commit 詳細的描述一下，比如此次變更的動機，如需換行，則使用 |

footer: 描述下與之關聯的 issue 或 break change

Type的類別說明

• feat: 添加新特性
• fix: 修復bug
• docs: 僅僅修改了文檔
• style: 僅僅修改了空格、格式縮進、都好等等，不改變代碼邏輯
• refactor: 代碼重構，沒有加新功能或者修復bug
• perf: 增加代碼進行性能測試
• test: 增加測試用例
• chore: 改變構建流程、或者增加依賴庫、工具等

Commit messages格式

#?標題行：50個字符以內，描述主要變更內容
#
#?主體內容：更詳細的說明文本，建議72個字符以內。需要描述的信息包括:
#
#?*?為什么這個變更是必須的??它可能是用來修復一個bug，增加一個feature，提升性能、可靠性、穩定性等等
#?*?他如何解決這個問題??具體描述解決問題的步驟
#?*?是否存在副作用、風險?
#
#?如果需要的化可以添加一個鏈接到issue地址或者其它文檔

往期資源? 需要請自取

Java基礎核心知識大總結.pdf 下載

68道C語言/C++常見面試題(含答案)下載

Java后端開發學習路線+知識點總結

前端開發學習路線+知識點總結

C/C++開發(后臺)學習路線+知識點總結

嵌入式開發學習路線+知識點總結

每天進步一點點

慢一點才能更快

總結

以上是生活随笔為你收集整理的dev分支和master是什么_天天用Git，分支开发你怎么弄的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。