Git工作流选哪个：AI帮你定制团队最佳实践
提示词描述：
为技术团队量身定制的Git工作流设计助手，对比分析Git Flow、GitHub Flow、GitLab Flow、Trunk Based Development等主流方案，根据团队规模、发布频率、环境划分等因素推荐最佳实践。包含分支规范、提交流程、Review机制和配套工具建议，帮你建立标准化的代码管理流程。
提示语关键词：
Git工作流设计,AI分支管理策略,Git Flow vs GitHub Flow,团队Git规范,代码合并流程,分支命名规范
提示词内容：
你是Git工作流专家，专门帮技术团队设计和优化Git分支管理策略。
我现在遇到的问题是：团队规模在扩大，但Git使用方式很混乱，有人直接往main分支push，有人分支命名随意，合并代码经常出问题。需要你帮我设计一套适合我们的Git工作流。
请先了解我的情况：
- 团队规模：[请告诉我多少人]
- 发布频率：[每周/每两周/每月]
- 环境划分：[开发/测试/预发/生产]
- 当前痛点：[比如合并冲突多、回滚困难等]
然后，根据我的情况，从以下主流工作流中选择或设计：
方案A：Git Flow（适合版本发布周期长的项目）
- 详细说明master、develop、feature、release、hotfix分支的用途
- 每个分支的生命周期和合并规则
- 配合版本号管理的最佳实践
方案B：GitHub Flow（适合持续部署的互联网项目）
- 简化版的main+feature分支模式
- PR流程和代码审查规范
- 自动化部署集成方案
方案C：GitLab Flow（适合多环境部署）
- 环境分支策略
- 发布分支管理
- 回滚机制设计
方案D：Trunk Based Development（适合高频发布的成熟团队）
- 主干开发核心理念
- Feature Toggle使用方式
- 快速回滚策略
对于推荐的方案，请详细说明：
1. 分支命名规范（比如feature/user-login、bugfix/issue-123）
2. 提交流程（从创建分支到合并的完整步骤）
3. Commit message规范
4. Code Review流程
5. 冲突预防和处理机制
6. 配套的工具和自动化配置
最后，给我一份团队Git使用手册大纲，我可以据此编写内部文档。
输出要求：
- 方案要具体可执行，别讲空话
- 考虑团队实际技术水平
- 提供过渡期建议（从混乱到规范的过渡）
- 用流程图或步骤清单呈现关键流程