Git 工作流程

前言

在缺乏统一 Git 工作流的情况下，团队开发通常会出现以下问题：

• 分支结构混乱，无法判断代码当前所处阶段
• feature / release / hotfix 边界不清，代码随意合并，甚至根本就没有这些分支
• 冲突频繁且不可控，重复解决同类冲突
• 线上 bug 回溯困难，无法定位问题来源
• 无法做到多版本并行开发
• 因为分支混乱，发布节奏不可控

所以，本规范的目标是通过明确分支职责与流转路径，让代码在不同阶段的状态具备可追踪性与可控性。

分支管理

分支体系设计

类型	作用	生命周期
main	生产分支	长期
release	发布验证	临时
develop	集成开发	长期
feature	功能开发	短期
hotfix	线上修复	短期

主分支

1. 命名规则

main 或者 master

2. 定义

线上生产环境唯一来源分支。

main 的本质是 “可随时回滚的稳定快照”，而不是开发过程的一部分。

3. 规则（硬约束）

• ❌ 禁止直接 commit
• ❌ 禁止直接 push feature 代码
• ❌ 禁止未验证代码合并
• ✔ 仅允许 develop / hotfix 合并

4. 发布原则

main = 已上线 + 已验证 + 可回滚

所有进入 main 的代码，都必须满足 “已经在 release 环境验证过” 的前提。

铭记

任何时间，任何时候都不能直接修改主分支的代码。

开发集成分支

1. 命名规则

中小型项目：

pre_(master/main)_项目版本号_dev

大型项目

当系统存在多个模块独立迭代时，需要按模块拆分 develop，避免所有功能集中导致冲突放大。

命名：pre_(master/main)_模块名_版本号

2. 定义

团队开发的集成分支，用于汇总 feature 开发成果。

develop 的本质是 “开发态主干”，用于承接所有 feature 的集成结果。

3. 来源

从 main 初始化创建而来

4. 职责

• 汇总 feature 分支（作为开发阶段的统一集成点）
• 保持最新开发进度
• 提供 release 分支的构建基础（用于进入发布验证阶段）

5. 规则

• ✔ feature 必须合并到 develop
• ✔ release 必须基于 develop 创建
• ✔ release 验证通过后，develop 才具备合并回 main 的资格
• ❌ 禁止未经 release 验证直接合并 main

功能分支

1. 命名规则

pre_master_模块名_版本号_功能名_开发者姓名简写

2. 定义

单一功能开发分支（最小开发单元）

feature 的设计目标是 “隔离变更”，避免多人修改同一代码空间。

3. 来源

从 develop 分支切出

4. 规则

• ✔ 一个分支只做一个功能
• ✔ 支持并行多个 feature 开发
• ✔ 完成后必须合并回 develop
• ❌ 禁止直接合并 main / release

发布分支

1. 命名规则

release

2. 定义

发布前冻结分支，仅用于测试与稳定性修复。

3. 来源

第一次由 develop 分支生成，之后也是从 develop 分支同步。

4. 职责

• QA 测试
• 发布前 bug 修复
• 发布前稳定化

5. 规则

• ❌ 不允许合入 feature
• ❌ 不允许合入 develop
• ❌ 不允许直接合入 main

热修复分支

1. 命名规则

hotfix_(master/main)_模块名/功能名_开发者姓名简写

2. 定义

生产环境紧急问题修复分支，特点是绕过开发流程，但必须向开发集成分支回流修复。

3. 来源

从 main 切出

4. 生命周期

hotfix -> main -> develop（选择性回流开发分支 cherry-pick）

5. 规则

• ✔ 修复必须同步回 develop（避免版本分裂）

Git 工作流程图

冲突处理规范

禁止行为

• feature 不允许直接拉 main 解冲突
• feature 不允许污染生产代码

标准流程

第一步

从 main 分支切出一个分支命名为 conflict_main_merge_目标分支名

命名示例 conflict_main_merge_pre_main_1.9.0_dev

第二步

在新创建的 conflict 分支中，拉取并合并 pre_main_1.9.0_dev 分支。

解决好冲突并验证代码正确以后，再将该分支合并至主分支。

第三步

合并完成并确认无误，就删除 conflict 分支，确保远端分支结构的简洁性。

严禁行为

严禁将 pre_main_1.9.0_dev 分支作为源分支拉取 main 分支的代码处理合并冲突。

这会导致 pre_main_1.9.0_dev 分支上出现其他版本的代码。

Commit 提交规范

提交格式

使用 type(scope): subject 结构进行提交，类型和作用域用来明确提交的内容和范围。

示例：

✨ feat: 添加了什么功能
🐞 fix: 解决了什么bug

常见提交类型

- ✨ feat: 新功能
- 🐞 fix: 修复 Bug
- 🚀 perf: 性能优化
- 🦄 refactor: 代码重构（不改变功能行为）
- 🚨 hotfix: 线上紧急修复（生产问题快速修复）

- 🗑️ delete: 删除文件 / 冗余资源 / 废弃代码
- ♻️ cleanup: 清理冗余逻辑 / 无用代码 / 历史垃圾代码
- 🧹 remove: 功能移除（业务能力下线 / 模块能力移除）

- 📃 docs: 文档修改
- 🎨 style: 代码样式调整（不影响逻辑）

- ⏪ revert: 回滚提交（撤销历史变更）
- 🚧 wip: 开发中临时提交（禁止长期存在 / 禁止合入主干）

- 🧪 test: 测试相关新增 / 修改
- 🔧 build: 构建系统相关修改（Gradle / CI / 构建脚本）
- 📦 deps: 依赖升级 / 降级 / 锁定版本
- 🧱 chore: 工程维护类改动（工具、脚本、模板、无业务变更）

- ⚙️ config: 配置类修改（环境配置、开关、feature flag）
- 📱 android: Android 平台相关改动（Manifest / Gradle / 兼容性 / 系统适配）
- 🧩 module: 模块结构调整（拆分 / 合并 / 目录重组）
- 🧷 api: 对外接口 / SDK API 变更

约束

• 单 commit 只做一件事
• subject 原则上 ≤ 50 字

版本控制

遵循语义化版本格式：Major.Minor.Patch，即 主版本号.次版本号.补丁版本号。

规则：

• 1. 主版本号（Major）

表示重大变更，不向后兼容的更新。

• 2. 次版本号（Minor）

表示向后兼容的新增功能。

• 3. 补丁版本号（Patch）

表示向后兼容的 bug 修复。

Git Tag 标签

在主分支发布新版本时，务必遵循规范创建版本 Tag 标签，以确保版本管理的清晰和可追溯性。

其他标记

先行版本号（Pre-release）

表示尚未正式发布的阶段性版本，用于区分发布前不同稳定程度。

版本名一般为：1.0.0-alpha 或 1.0.0-beta、1.0.0-rc.1

各阶段意义：

• alpha：内部开发版本（不稳定）
• beta：测试版本（可用于验证功能）
• rc：发布候选版本（接近正式发布）

---

标记名称可以根据实际的项目情况自定义。

Git 分支生命周期

这个图展示了项目从功能开发到版本发布的完整 Git 分支流转过程，涵盖 Feature 开发、Develop 集成、Release 验证、Main 发布、Hotfix 修复以及冲突处理等关键阶段。

其他注意事项

代码提交频率

• 小步提交
• 避免大批量一次提交
• 每次提交只解决一个问题

分支清理

• feature / hotfix 合并后必须删除，保持仓库结构清晰
• 定期清理远端旧分支