2022-04-16-【工程化】git全流程规范

1. 引言

1.1 目的

为了有效地帮助团队更简洁、更统一地管理源码，加强源码提交历史的清晰可读性，从源头强化开发过程管理，从而更有效地保证产品质量，特制定本规范。

1.2 适用范围

本规范适用于所有软件开发人员，包括架构师、开发工程师、测试工程师以及需要使用源码仓库的相关人员。

2. Git Flow 分支管理规范

Git Flow 是一种经典的 Git 分支管理模型，它定义了一组明确的分支及其使用场景，帮助团队并行开发、管理发布和修复 Bug。

2.1 分支概览

源码仓库的分支按照生命周期和用途分为以下几类：

分支类型 命名规范 来源 合并去向 说明
Master master - - 主分支/生产分支。存放随时可上生产的稳定代码。
Develop develop 或 dev master - 开发分支。所有最新功能开发的汇总地。
Feature feature/xxx develop develop 功能分支。用于开发新功能。
Release release/vX.Y.Z develop develop, master 预发布分支。用于发布前的测试和准备。
Hotfix hotfix/xxx master develop, master 热修复分支。用于紧急修复生产环境 Bug。

2.2 分支详细说明

2.2.1 Master 分支 (主分支)

  • 用途：作为发布基线，与生产环境代码保持严格一致。
  • 保护策略：仅管理员有权限合并，严禁直接 Push 代码。
  • Tag 规范：每次合并到 Master 后，必须打上版本 Tag（如 v1.0.0）。

2.2.2 Develop 分支 (开发分支)

  • 用途：日常开发的主分支，包含所有已完成的特性。
  • 保护策略：开发人员可提交，但建议通过 Merge Request (MR) 合并。

2.2.3 Feature 分支 (功能分支)

  • 用途：开发新功能。
  • 命名建议：feature/功能描述_日期_开发者 或 feature/需求ID-简述。
    • 例：feature/user-login_20220416_sunny
    • 例：feature/31124-comment-module
  • 生命周期：从 develop 创建，开发完成后合并回 develop，之后删除。

2.2.4 Release 分支 (预发布分支)

  • 用途：发布正式版本前的预发布测试。在此分支上只进行 Bug 修复，不添加新功能。
  • 命名建议：release/v版本号，如 release/v1.1.0。
  • 生命周期：从 develop 创建，测试通过后合并回 master 和 develop，之后删除。

2.2.5 Hotfix 分支 (热修复分支)

  • 用途：修复生产环境的紧急 Bug。
  • 命名建议：hotfix/Bug描述_日期 或 hotfix/版本号-修复内容。
    • 例：hotfix/fix-login-error_20220417
  • 生命周期：从 master 创建，修复后合并回 master 和 develop，之后删除。

3. 工作流程实战

3.1 功能开发流程 (Feature)

git分支管理

  1. 创建分支：从 develop 拉取最新代码，创建功能分支。

    1
    2
    3
    git checkout develop
    git pull origin develop
    git checkout -b feature/comment-module

  2. 开发与提交：在分支上进行开发，定期 Commit。

    1
    2
    git add .
    git commit -m "feat: 完成评论列表接口对接"

  3. 保持同步：开发过程中，建议定期合并 develop 代码，避免冲突堆积。

    1
    git merge --no-ff develop

  4. 合并代码：开发完成后，通过 MR 或命令行合并回 develop。

    1
    2
    3
    4
    git checkout develop
    git pull origin develop
    git merge --no-ff feature/comment-module
    git push origin develop

  5. 删除分支：

    1
    git branch -d feature/comment-module

3.2 版本发布流程 (Release)

git分支管理

  1. 创建预发布分支：功能开发完毕，准备发布 v1.1.0。

    1
    2
    git checkout develop
    git checkout -b release/v1.1.0

  2. 测试与修复：部署到预发布环境测试。发现 Bug 直接在该分支修复。

  3. 完成发布：测试通过后，合并到 master 和 develop。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    # 合并到 master
    git checkout master
    git merge --no-ff release/v1.1.0
    # 打标签
    git tag -a v1.1.0 -m "Release v1.1.0"
    git push origin master --tags

    # 合并回 develop (确保修复的Bug同步回开发分支)
    git checkout develop
    git merge --no-ff release/v1.1.0
    git push origin develop

  4. 删除分支：

    1
    git branch -d release/v1.1.0

3.3 紧急修复流程 (Hotfix)

  1. 创建修复分支：生产环境 v1.1.0 发现 Bug，需要紧急修复。

    1
    2
    git checkout master
    git checkout -b hotfix/v1.1.1-fix-login

  2. 修复 Bug：修改代码并验证。

  3. 合并修复：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    # 合并到 master
    git checkout master
    git merge --no-ff hotfix/v1.1.1-fix-login
    git tag -a v1.1.1 -m "Hotfix v1.1.1"
    git push origin master --tags

    # 合并回 develop
    git checkout develop
    git merge --no-ff hotfix/v1.1.1-fix-login
    git push origin develop

4. Git Commit 提交规范

规范的 Commit Message 能让团队快速了解代码变更历史，方便回溯和生成 Changelog。

4.1 格式说明

遵循 Angular 团队的规范，Commit Message 包括三个部分：Header，Body 和 Footer。

1
2
3
4
5
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>

其中，Header 是必需的，Body 和 Footer 可以省略。

4.2 Header 详解

Header 只有一行，包括三个字段：type（必需）、scope（可选）和 subject（必需）。

Type (变更类型)

用于说明 commit 的类别，只允许使用以下标识：

  • feat: 新功能 (feature)
  • fix: 修补 Bug
  • docs: 文档修改 (documentation)
  • style: 代码格式修改 (不影响代码运行的变动，如空格、分号等)
  • refactor: 代码重构 (即不是新增功能，也不是修改 bug 的代码变动)
  • perf: 性能优化 (Performance)
  • test: 增加或修改测试用例
  • build: 编译系统或外部依赖变更 (如 webpack, npm, gulp 等)
  • ci: CI 配置或脚本变更 (如 Travis, Circle 等)
  • chore: 其他不修改 src 或 test 的变更 (如构建过程或辅助工具的变动)
  • revert: 回滚上一次 commit

Scope (影响范围)

用于说明 commit 影响的范围，例如数据层、控制层、视图层等，视项目而定。

Subject (简述)

commit 目的的简短描述，不超过 50 个字符。

  • 以动词开头，使用第一人称现在时，比如”change”，而不是”changed”或”changes”
  • 第一个字母小写
  • 结尾不加句号（.）

4.3 示例

1
2
3
4
feat(user): 添加用户登录接口

- 完成登录验证逻辑
- 添加 JWT Token 生成
1
fix(style): 修复首页样式兼容性问题

5. 代码合并与审查 (Code Review)

5.1 Merge Request (MR) 规范

  • 标题前缀：建议在标题中添加 [MR] 前缀，或使用 feat: xxx 格式。
  • 单一主题：每个 MR 应该仅包含针对单一主题的一系列变更。不要在一个 MR 中混合多个无关功能的修改，以免 Reviewer 难以决策。
  • 指定 Reviewer：每个 MR 提交人必须指定至少一名 Code Reviewer 进行代码审查。

5.2 冲突解决

特性代码开发过程中，在提交 MR 或 Push 代码前，建议先在本地做 rebase，解决可能存在的冲突。

1
2
3
4
5
6
7
# 拉取远程 develop 代码并变基
git checkout feature/xxx
git pull --rebase origin develop
# 解决冲突后
git add .
git rebase --continue
git push origin feature/xxx -f

6. 进阶管理

6.1 多模块项目管理 (Submodule)

对于包含多个模块的版本交付包，可以使用 git submodule 管理多仓代码。

  • 初始化: git submodule update --init --remote
  • 添加模块: git submodule add <repository> <path>
  • 批量操作: git submodule foreach <command>

6.2 定制化开发

  • 定制项目：从指定 Tag 版本拉出单独分支进行维护。
  • ISV 定制：ISV 基于版本 Tag 克隆代码自行维护。

7. 总结

规范化的 Git 流程是团队协作的基石。

  1. 分支管理：明确了代码流向，保证了生产环境的稳定性。
    • 开发在 dev，发布走 release，生产看 master，修 Bug 用 hotfix。
  2. 提交规范：清晰的 Commit Message 让历史可追溯，便于自动化工具生成日志。
    • 多用 feat 和 fix，保持描述简洁准确。

希望团队成员严格遵守本规范，共同维护高质量的代码仓库。

工程化
#Git #Git Flow
2022-04-16-【工程化】git全流程规范
https://zhangyingxuan.github.io/2022-04-16-【工程化】git全流程规范/
作者
blowsysun
更新于
2026年1月23日
许可协议