Git提交记录和GitFlow工作流

作者: veaxen 分类: Git/Svn 发布时间: 2019-04-01 15:54

Git提交记录

本文介绍一种名为 AngularJS’s commit message convention 的提交格式,具体如下:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
  • subject 是对变更的简要描述
  • body 是更为详细的描述
  • type 则定义了此次变更的类型,只能使用下面几种类型:
    • feat: 增加新功能
    • fix: 问题修复
    • docs: 文档变更
    • style: 代码风格变更(不影响功能)
    • refactor: 既不是新功能也不是问题修复的代码变更
    • perf: 改善性能
    • test: 增加测试
    • chore: 开发工具(构建,脚手架工具等)
  • footer 可以包含 Breaking Changes 和 Closes 信息

应用

node-trail-agent 项目遵循 conventional message,这里以这个项目举例,演示其应用场景。

CHANGELOG

通过 git log 可以生成 CHANGELOG.md 中版本间新增功能,

$ git log v0.4.0..v1.1.2 --grep feat --pretty=format:%s

feat: add "type" tag to distinguish client and server span
feat: instrument via Module._load hook

也可以同时获取修复的问题,

$ git log v0.4.0..v1.1.2 --grep 'feat\|fix' --pretty=format:%s

fix: wrapper function not returned
feat: add "type" tag to distinguish client and server span
feat: instrument via Module._load hook

定位错误

使用 git bisect 可以定位引入问题的提交,通过 type 可以快速辨别不会引入 bug 的提交,

(master) $ git bisect start
(master) $ git bisect bad
(master) $ gco v0.1.0
(7f04616) $ git bisect good

Bisecting: 15 revisions left to test after this (roughly 4 steps)
[433f58f26a53b519ab7fc52927895e67eb068c64] docs: how to use agent

(433f58f) $ git bisect good

Bisecting: 7 revisions left to test after this (roughly 3 steps)
[02894fb497f41eecc7b21462d3b020687b3aaee2] docs(CHANGELOG): 1.1.0

(02894fb) $ git bisect good

Bisecting: 3 revisions left to test after this (roughly 2 steps)
[9d15ca2166075aa180cd38a3b4d3be22aa336575] chore(release): 1.1.1

(9d15ca2) $ git bisect good

Bisecting: 1 revision left to test after this (roughly 1 step)
[f024d7c0382c4ff8b0543cbd66c6fe05b199bfbc] fix: wrapper function not returned

(f024d7c) $ npm test
...

因为 docs 或 chore 不会引入 bug,所以可以直接执行 git bisect good

使用 git bisect skip 可以直接过滤掉这些提交,

$ git bisect skip $(git rev-list --grep 'style\|docs\|chore' v0.1.0..HEAD)

Git工作流指南:Gitflow工作流

请记住:流程应被视作为指导方针,而非“铁律”。我们只是想告诉你可能的做法。因此,如果有必要的话,你可以组合使用不同的流程。

在整个开发流程中,始终存在 master 和 develop 分支,其中 master 分支代码和生产环境代码保持一致,develop 分支还包括新功能代码。

分支模型主要涉及三个过程:功能开发,代码发布和问题修复。

功能开发

  1. 从 develop 创建一个新分支(feature/*)
  2. 功能开发
  3. 生产环境测试
  4. Review
  5. Merge 回 develop 分支

代码发布

需要发布新功能到生产环境时

  1. 从 develop 创建新分支(release/*)
  2. 发布 feature 分支代码到预上线环境
  3. 测试并修复问题
  4. Review
  5. 分别 merge 回 develop 和 master 分支
  6. 发布 master 代码到生产环境

问题修复

当生产环境代码出现问题需要立刻修复时

  1. 从 master 创建新分支(hotfix/*)
  2. 发布 hotfix 代码到预上线环境
  3. 修复问题并测试
  4. Review
  5. 分别 merge 会 develop 和 master 分支
  6. 发布 master 代码到生产环境

该分支模型值得借鉴的地方包括,

  • 规范的分支命名
  • 将分支和代码运行环境关联起来

分支和代码运行环境的关系是这样的,

  • master => 生产环境
  • release/,hotfix/ => 预上线环境
  • feature/*,develop => 开发环境

修改自:《Git提交记录和分支模型》

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据