概述
Git Workflow Strategy 旨在帮助团队建立高效的 Git 工作流，通过结构化的分支策略与合并模式支持团队协作、代码质量和部署就绪度。
适用时机
该指南适用于以下场景：
- 团队协作环境搭建
- 发布管理
- 功能开发协调
- 热修复（hotfix）流程
- 代码评审流程
- CI/CD 集成规划
快速上手
指南提供了一个最小可用示例，覆盖 GitFlow 的初始化、功能分支、发布分支与热修复分支的完整流程：
# Initialize GitFlow
git flow init -d
# Start a feature
git flow feature start new-feature
# Work on feature
git add .
git commit -m "feat: implement new feature"
git flow feature finish new-feature
# Start a release
git flow release start 1.0.0
# Update version numbers, changelog
git add .
git commit -m "chore: bump version to 1.0.0"
git flow release finish 1.0.0
# Create hotfix
git flow hotfix start 1.0.1
# Fix critical bug
git add .
git commit -m "fix: critical bug in production"
git flow hotfix finish 1.0.1
参考指南
在 references/ 目录中提供详细实现：
| 指南 | 内容 |
|---|---|
| GitFlow Workflow Setup | GitFlow 工作流设置、GitHub Flow 工作流、Trunk-Based Development、用于工作流的 Git 配置（+1 更多） |
| Merge Strategy Script | 合并策略脚本 |
| Collaborative Workflow with Code Review | 带代码评审的协作工作流 |
最佳实践
建议做法
- 选择与团队规模和发布周期相匹配的工作流
- 保持功能分支短生命周期（少于 3 天）
- 使用带类型前缀的描述性分支名
- 合并到 main 前要求代码评审
- 对 main/release 分支启用保护规则
- 频繁 rebase 以减少冲突
- 编写原子化、逻辑清晰的提交
- 保持提交信息清晰且一致
应避免做法
- 直接提交到 main 分支
- 创建长期存活的功能分支
- 使用模糊的分支名（dev、test、temp）
- 未经代码评审就合并
- 在一个分支中混合多个功能
- 向共享分支强制推送
- 忽略失败的 CI 检查
- 在 TBD 中使用合并提交进行合并
限制与未提供信息
资料未提供该工作流的具体授权许可、定价、平台依赖或维护状态等信息；相关细节暂未提供。