gitflow

Gitflow

此技能涵盖 Gitflow 分支模型：两个长期分支、三种辅助分支类型、提交消息规范、语义化版本控制，以及发布和热修复流程。

功能变更工作流

1. 同步 develop — 运行 git checkout develop && git pull origin develop，确保功能分支基于最新的开发状态创建。
2. 创建功能分支 — 运行 git checkout -b feature/123-user-authentication，并遵循命名规范 feature/[issue-id]-descriptive-name。
3. 使用约定式消息提交 — 每次提交都使用 type(scope): description 格式（参见下文的提交消息）。
4. 变基或合并 develop — 打开 PR 之前，先让分支保持最新：git fetch origin && git rebase origin/develop（或按团队约定进行合并）。
5. 向 develop 创建拉取请求 — 至少需要一项审批且 CI 检查通过；绝不直接提交到 develop。
6. 合并并清理 — 合并后，在本地和远程删除功能分支：git branch -d feature/123-user-authentication && git push origin --delete feature/123-user-authentication。

主要分支

main（或 master）

• 仅包含可用于生产环境的代码。
• 绝不直接提交到 main。
• 仅接受来自 hotfix/* 或 release/* 分支的合并。
• 每次合并后都必须打上版本号标签（例如 git tag -a v1.2.0 -m "Release 1.2.0"）。

develop

• 主要集成分支；包含最新交付的开发变更。
• 所有 feature/* 分支的源分支。
• 绝不直接提交到 develop——所有变更都通过拉取请求合入。

辅助分支

feature/*

• 从以下分支创建：develop。
• 合并回：develop。
• 命名规范：feature/[issue-id]-descriptive-name（例如 feature/123-user-authentication）。
• 打开 PR 之前必须与 develop 保持同步。
• 合并后删除。

release/*

• 从以下分支创建：develop。
• 合并回：main 和 develop。
• 命名规范：release/vX.Y.Z（例如 release/v1.2.0）。
• 范围仅限于错误修复、文档和面向发布的任务——不得添加新功能。
• 合并后删除。

hotfix/*

• 从以下分支创建：main。
• 合并回：main 和 develop。
• 命名规范：hotfix/vX.Y.Z（例如 hotfix/v1.2.1）。
• 仅用于紧急生产环境修复。
• 合并后删除。

提交消息

使用约定式提交格式：type(scope): description。

类型	含义
feat	新功能
fix	错误修复
docs	文档变更
style	格式调整、缺少分号等——不改变逻辑
refactor	重构代码，不改变行为
test	添加或修正测试
chore	维护任务（构建脚本、依赖升级）

示例：

feat(auth): add refresh-token rotation

fix(orders): prevent duplicate charge on retry

chore(deps): bump lodash to 4.17.21

语义化版本控制

对于版本 MAJOR.MINOR.PATCH：

• MAJOR — 不兼容或破坏性 API 变更时递增。
• MINOR — 向后兼容的新功能时递增。
• PATCH — 向后兼容的错误修复时递增。

拉取请求规则

1. 所有变更都必须通过拉取请求进行——main 或 develop 均无例外。
2. 合并前至少需要一项审批。
3. 所有 CI 检查都必须通过。
4. 不得直接提交到受保护分支（main、develop）。
5. 合并前，分支必须与目标分支保持同步。
6. 合并后删除分支（包括本地和远程副本）。

分支保护规则

对 main 和 develop 均应用以下规则：

• 合并前必须经过拉取请求审查。
• 合并前必须通过状态检查。
• 合并前必须确保分支为最新状态。
• 将管理员也纳入限制范围（不得使用更高权限绕过规则）。
• 禁止强制推送。
• 禁止删除分支。

发布流程

1. 从 develop 创建发布分支：git checkout -b release/v1.2.0 develop。
2. 更新软件包清单／变更日志中的版本号。
3. 修复所有发布专属问题（文档、最后一刻发现的 Bug）——不要添加新功能。
4. 创建从发布分支合并到 main 的 PR。
5. 合并到 main 后：
   • 为发布打标签：git tag -a v1.2.0 -m "Release 1.2.0"，然后推送标签。
   • 将 main 合并回 develop，确保 develop 包含此次发布提交和标签。
   • 删除发布分支。

热修复流程

1. 从 main 创建热修复分支：git checkout -b hotfix/v1.2.1 main。
2. 以尽可能小的改动修复生产环境问题。
3. 更新补丁版本号。
4. 创建从热修复分支合并到 main 的 PR。
5. 合并到 main 后：
   • 为发布打标签：git tag -a v1.2.1 -m "Hotfix 1.2.1"，然后推送标签。
   • 将 main 合并回 develop，确保修复不会在下一次发布时丢失。
   • 删除热修复分支。