這應(yīng)該是全網(wǎng)最全的Git分支開發(fā)規(guī)范手冊~
Git 是目前最流行的源代碼管理工具。為規(guī)范開發(fā)，保持代碼提交記錄以及 git 分支結(jié)構(gòu)清晰，方便后續(xù)維護，現(xiàn)規(guī)范 git 的相關(guān)操作。
# 分支命名
master 分支
develop 分支
feature 分支
release分支
當(dāng)有一組feature開發(fā)完成，首先會合并到develop分支，進入提測時會創(chuàng)建release分支。如果測試過程中若存在bug需要修復(fù)，則直接由開發(fā)者在release分支修復(fù)并提交。當(dāng)測試完成之后，合并release分支到master和develop分支，此時master為最新代碼，用作上線。
hotfix 分支
# 常見任務(wù)
增加新功能
(dev)$: git checkout -b feature/xxx # 從dev建立特性分支(feature/xxx)$: blabla # 開發(fā)(feature/xxx)$: git add xxx(feature/xxx)$: git commit -m 'commit comment'(dev)$: git merge feature/xxx --no-ff # 把特性分支合并到dev
修復(fù)緊急bug
(master)$: git checkout -b hotfix/xxx # 從master建立hotfix分支(hotfix/xxx)$: blabla # 開發(fā)(hotfix/xxx)$: git add xxx(hotfix/xxx)$: git commit -m 'commit comment'(master)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到master，并上線到生產(chǎn)環(huán)境(dev)$: git merge hotfix/xxx --no-ff # 把hotfix分支合并到dev，同步代碼
測試環(huán)境代碼
(release)$:?git?merge?dev?--no-ff?????????????#?把dev分支合并到release，然后在測試環(huán)境拉取并測試生產(chǎn)環(huán)境上線
(master)$: git merge release --no-ff # 把release測試好的代碼合并到master，運維人員操作(master)$:?git?tag?-a?v0.1?-m?'部署包版本名'??#給版本命名，打Tag
# 日志規(guī)范
在一個團隊協(xié)作的項目中，開發(fā)人員需要經(jīng)常提交一些代碼去修復(fù)bug或者實現(xiàn)新的feature。
而項目中的文件和實現(xiàn)什么功能、解決什么問題都會漸漸淡忘，最后需要浪費時間去閱讀代碼。但是好的日志規(guī)范commit messages編寫有幫助到我們，它也反映了一個開發(fā)人員是否是良好的協(xié)作者。
編寫良好的Commit messages可以達到3個重要的目的：
加快review的流程
幫助我們編寫良好的版本發(fā)布日志
讓之后的維護者了解代碼里出現(xiàn)特定變化和feature被添加的原因
目前，社區(qū)有多種 Commit message 的寫法規(guī)范。來自Angular 規(guī)范是目前使用最廣的寫法，比較合理和系統(tǒng)化。如下圖：
# Commit messages的基本語法
當(dāng)前業(yè)界應(yīng)用的比較廣泛的是 Angular Git Commit Guidelines
“https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines
具體格式為:
<type>: <subject><BLANK LINE><body><BLANK LINE><footer>
type: 本次 commit 的類型，諸如 bugfix docs style 等
scope: 本次 commit 波及的范圍
subject: 簡明扼要的闡述下本次 commit 的主旨，在原文中特意強調(diào)了幾點：
使用祈使句，是不是很熟悉又陌生的一個詞
首字母不要大寫
結(jié)尾無需添加標(biāo)點
body: 同樣使用祈使句，在主體內(nèi)容中我們需要把本次 commit 詳細的描述一下，比如此次變更的動機，如需換行，則使用 |
footer: 描述下與之關(guān)聯(lián)的 issue 或 break change
# Type的類別說明：
feat: 添加新特性 fix: 修復(fù)bug docs: 僅僅修改了文檔 style: 僅僅修改了空格、格式縮進、都好等等，不改變代碼邏輯 refactor: 代碼重構(gòu)，沒有加新功能或者修復(fù)bug perf: 增加代碼進行性能測試 test: 增加測試用例 chore: 改變構(gòu)建流程、或者增加依賴庫、工具等
# Commit messages格式要求
# 標(biāo)題行：50個字符以內(nèi)，描述主要變更內(nèi)容## 主體內(nèi)容：更詳細的說明文本，建議72個字符以內(nèi)。需要描述的信息包括:## * 為什么這個變更是必須的? 它可能是用來修復(fù)一個bug，增加一個feature，提升性能、可靠性、穩(wěn)定性等等# * 他如何解決這個問題? 具體描述解決問題的步驟# * 是否存在副作用、風(fēng)險?## 如果需要的化可以添加一個鏈接到issue地址或者其它文檔
來源：https://www.cnblogs.com/heroljy/p/9294127.html 推薦閱讀
GitHub 熱榜：標(biāo)星 1.6w，黑客必看的黑魔法開發(fā)指南！
最后，推薦給大家一個有趣有料的公眾號：寫代碼的渣渣鵬，7年老程序員教你寫bug,回復(fù) 面試或資源 送一你整套開發(fā)筆記 有驚喜哦
