2. 程式人生 > >Git commit message和工作流規範

Git commit message和工作流規範

阿新 • • 發佈：2019-10-09

目的

  • 統一團隊Git commit日誌標準，便於後續程式碼review，版本釋出以及日誌自動化生成等等。
  • 統一團隊的Git工作流，包括分支使用、tag規範、issue等

Git commit日誌參考案例

 

總體方案

Git commit日誌基本規範

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

對格式的說明如下：

  • type代表某次提交的型別，比如是修復一個bug還是增加一個新的feature。所有的type型別如下：
  • feat： 新增feature
  • fix: 修復bug
  • docs: 僅僅修改了文件，比如README, CHANGELOG, CONTRIBUTE等等
  • style: 僅僅修改了空格、格式縮排、都好等等，不改變程式碼邏輯
  • refactor: 程式碼重構，沒有加新功能或者修復bug
  • perf: 優化相關，比如提升效能、體驗
  • test: 測試用例，包括單元測試、整合測試等
  • chore: 改變構建流程、或者增加依賴庫、工具等
  • revert: 回滾到上一個版本

格式要求：

# 標題行：50個字元以內，描述主要變更內容
#
# 主體內容：更詳細的說明文字，建議72個字元以內。 需要描述的資訊包括:
#
# * 為什麼這個變更是必須的? 它可能是用來修復一個bug，增加一個feature，提升效能、可靠性、穩定性等等
# * 他如何解決這個問題? 具體描述解決問題的步驟
# * 是否存在副作用、風險? 
#
# 尾部：如果需要的化可以新增一個連結到issue地址或者其它文件，或者關閉某個issue。

Git分支與版本釋出規範

  • 基本原則：master為保護分支，不直接在master上進行程式碼修改和提交。
  • 開發日常需求或者專案時，從master分支上checkout一個feature分支進行開發或者bugfix分支進行bug修復，功能測試完畢並且專案釋出上線後，將feature分支合併到主幹master，並且打Tag釋出，最後刪除開發分支
    。分支命名規範：
    • 分支版本命名規則：分支型別 _ 分支釋出時間 _ 分支功能。比如：feature_20170401_fairy_flower
    • 分支型別包括：feature、 bugfix、refactor三種類型，即新功能開發、bug修復和程式碼重構
    • 時間使用年月日進行命名，不足2位補0
    • 分支功能命名使用snake case命名法，即下劃線命名。
  • Tag包括3位版本，字首使用v。比如v1.2.31。Tag命名規範：
    • 新功能開發使用第2位版本號，bug修復使用第3位版本號
    • 核心基礎庫或者Node中間價可以在大版本釋出請使用灰度版本號，在版本後面加上字尾，用中劃線分隔。alpha或者belta後面加上次數，即第幾次alpha：
      • v2.0.0-alpha-1
      • v2.0.0-belta-1
  • 版本正式釋出前需要生成changelog文件，然後再發布上線。

如何接入？

接入參考commit-message-test-project專案。具體步驟如下：

  • 第一步：在工程跟目錄下的package.json檔案加入如下程式碼所示的scripts和dependencies內容，版本號為3位版本號。
  {
    "name": "application-name",
    "version": "0.1.0",
    "scripts": {
      "commitmsg": "validate-commit-msg",
      "commit": "git-cz ",
      "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0"
    },
    "devDependencies": {
      "commitizen": "^2.3.0",
      "validate-commit-msg": "^2.11.1",
      "conventional-changelog-cli": "^1.2.0",
      "husky": "^0.13.1"
    }
  }
  • 第二步：在工程根目錄新建.vcmrc檔案，並且檔案內容為
{
  "helpMessage": "\nPlease fix your commit message (and consider using https://www.npmjs.com/package/commitizen)\n",
  "types": [
    "feat",
    "fix",
    "docs",
    "style",
    "refactor",
    "perf",
    "test",
    "chore",
    "revert"
  ],
  "warnOnFail": false,
  "autoFix": false
}

接入後的Git commit操作流程

  • 第一步：建立一個feature分支或者bugfix分支
    sh $ git checkout -b feature_infinite_load # 切換到一個feature分支或者bug fix分支 sh

  • 第二步：將程式碼提交到本地Git倉庫，並填寫符合要求的Commit message格式
  $ git add .                                
  $ git commit                               # 此處不要加任何引數，比如-m

如下圖所示：

  • 第三步：將程式碼同步到遠端Git倉庫
  $ git push origin feature_infinite_load    # 將修改釋出到遠端倉庫
  • 第四步：自動生成changelog，並打Tag釋出
  $ tnpm run changelog                    # 使用npm script中的changlog命令直接從git元資料生成日誌。
  $ git tag v0.1.0
  $ git push origin v0.1.0

相關推薦

Git commit message和工作流規範

目的 統一團隊Git commit日誌標準，便於後續程式碼review，版本釋出以及日誌自動化生成等等。 統一團隊的

git分支管理及git commit message規範

分支管理 如圖所示： master分支只用於存放線上版本 線上緊急bug，使用hot-fix分支 開發在dev分支上，小的測試bug也可在dev分支修改。線上緊急修復bug也需合併到dev分支 開發複雜的新功能可新建分支dev-${devName} Git Commit message

規範Git Commit Message

讓Commitlint支援Angular規範 一、安裝依賴： 1、自動檢測依賴安裝 npm install --save-dev @commitlint/config-angular @commitlint/cli 或者用yarn yarn add @commitl

前端工程工作流規範

在日常開發過程中，前端工程工作流程規範主要包括程式碼檢查規範以及程式碼提交規範。而程式碼檢查主要兩個部分：語法檢查及型別檢查；程式碼提交規範主要是Git Commit Log規範。 本文主要分享日常工作中，實現自動化工作流規範的幾種工具： 1、JavaScript語法檢查 - ESLint 2、Java

寫 git commit message 的錯誤姿勢 —— whatthecommit.com 到底說了些什麼

寫 git commit message 的錯誤姿勢 —— whatthecommit.com 到底說了些什麼 先介紹一下：www.whatthecommit.com，一個 Git 提交日誌生成網站。每次重新整理的內容隨機，不怕捱揍的壯士可以使用如下命令進行日常

悉數四代PaaS發展，一文理順基礎設施、平臺和工作流之間的關係_Kubernetes中文社群

Datawire團隊最近的一次交流，是關於“PaaS”這一術語的真正含義，以及它與開發人員體驗(DevEx)和工作流之間的關係，帶來了許多可以分享的內部對話。從和客戶一起工作，到會議上與人的聊天中，我感覺到，其他團隊對於部署應用程式時“平臺”和工作流之間的關係也有些不確定，我希望以建設性的方式

微信小程式 前端原始碼邏輯和工作流詳解

看完微信小程式的前端程式碼真的讓我熱血沸騰啊，程式碼邏輯和設計一目瞭然，沒有多餘的東西，真的是大道至簡。 廢話不多說，直接分析前端程式碼。個人觀點，難免有疏漏，僅供參考。 檔案基本結構：  先看入口app.js，app(obj)註冊一個小程式。接受一個 obje

git commit message form

commit message一般包括3部分：Header、Body、Footer。 <type>(<scope&

使用plumbing命令來深入理解git add和git commit的工作原理

clean 結果 write 文件的 repos 倉庫 head 根據 acc 前言： plumbing命令 和 porcelain命令 git中的命令分為plumbing命令和porcelain命令： porcelain命令就是我們常用的git add,git comm

Git基本命令和GitFlow工作流

本篇部落格講解了git的一些基本的團隊協作命令，和GitFlow工作流指南 git 團隊協作的一些命令 1.開分支 git branch 新分支名 例如，在master分支下，新開一個開發分支： git branch dev 2.切換到新分支 git checkou

git 工作流中的 Sourcetree 和命令列操作對比

git 工作流操作     1、初始化本地倉庫資料夾 終端進入專案資料夾 git init 隱藏資料夾中有 .git 資料夾則初始化成功     2、git 檢視倉庫狀態 這裡以新建一個 demo.txt 為例 ① sourcetr

activiti web流程設計器 工作流的 整合視頻教程 SSM和獨立部署

activiti 工作流 web流程設計器 ssm activiti工作流 本視頻為activiti工作流的web流程設計器整合視頻教程整合Acitiviti在線流程設計器(Activiti-Modeler 5.21.0 官方流程設計器）本視頻共講了兩種整合方式1. 流程設計器和其它工作流

工作流調度器azkaban的安裝和使用

用戶名 color smtp mail tex 服務器 重新 sts 建立 為什麽需要工作流調度系統 一個完整的數據分析系統通常都是由大量任務單元組成： 　　　　shell腳本程序，java程序，mapreduce程序、hive腳本等 各任務單元之間存在時間先後及前後

git config配置，工作區和版本庫聯系。

linu htm 相關 lfs global intro git bash .text desktop 關於git和github的介紹，我這邊不多說。 使用在windows下使用git，需要配置環境變量，也可以使用git自帶的終端工具。，打開git bash [e

git中Please enter a commit message to explain why this merge is necessary

eas csdn sof 退出 合並 comm 冒號 merge font 今天在使用git時，git pull和git merge時，經常出現如下錯誤信息： Please enter a commit message to explain why this merge

git add和git commit

stage mod com 指定 for 命令 現在 ssa -m git命令使用：提交前可指定要提交哪些文件，然後使用git commit來提交 樣例： git status 輸出： Changes to be committed: modified: ap

Git工作流指南：Gitflow工作流

lee 相對 技術 做的 tags finish 項目 ember 同時 這節介紹的Gitflow工作流借鑒自在nvie的Vincent Driessen。 Gitflow工作流定義了一個圍繞項目發布的嚴格分支模型。雖然比功能分支工作流復雜幾分，但提供了用於一個

Git工作流指南：Pull Request工作流

看到了 con 維護 work ont ria 而是 地址 org Pull Requests是Bitbucket上方便開發者之間協作的功能。提供了一個用戶友好的Web界面，在集成提交的變更到正式項目前可以對變更進行討論。 開發者向團隊成員通知功能開發已經完成，Pul

使用 Commitizen 撰寫 Angular 規範的 commit message

sin for bug semi fix doc -c existing new 本文為原創文章，轉載請標明出處 目錄 安裝及配置 使用 1. 安裝及配置 npm install -g commitizen npm install -g cz-conventional-

Git的工作模式和工作流程

Git 工作流程 git的優缺點 git屬於分布式版本控制系統：客戶端並不只提取最新版本的文件快照，而是把原始的代碼倉庫完整的鏡像下來。 優點： 1.由於任何人每次提取操作，實際上都是一次對代碼倉庫的完整備份，因此近乎所有的操作都可以在本地執行，速度就是相當的快，並且可以在網絡斷開的時候操作仍