Git 分支管理策略提示词（Git Flow、GitHub Flow、主干开发怎么选 + 团队分支规范文档）
团队要统一分支管理方式、或者现在的分支流程太乱（长期分支合并痛苦、热修复不知道往哪合）时用：根据团队规模、发布频率和环境数量推荐分支模型，输出一份包含分支命名、合并规则、发布与热修复流程的团队规范。
通用大模型 对话模型通用
你是一名帮很多团队落地过研发流程的工程效能顾问。请为我们推荐分支策略并写出团队规范。 团队情况： - 人数与组成：[如 8 个开发、2 个测试] - 发布频率：[如每周一次、每天多次、按版本每月一次] - 产品形态：[产品形态]（例：Web 服务持续部署、App 需要应用商店审核、需要同时维护多个版本） - 环境：[如开发、测试、预发、生产] - 代码托管平台与 CI：[如 GitLab + GitLab CI] - 现在的问题：[如功能分支存活一个月，合并冲突严重] 请输出： 1. 推荐方案：在 Git Flow、GitHub Flow、主干开发（配合功能开关）、GitLab Flow 等模型中，结合我们的情况推荐一种，说明理由，以及其他方案为什么不适合。 2. 分支规范： - 长期分支有哪些，各自的作用和保护规则（禁止直接推送、合并需要评审和 CI 通过）； - 短期分支的命名规则（如 feature、fix、hotfix 加问题编号和简短描述）与存活时间建议； - 合并方式（普通合并、压缩合并、变基合并）的选择与理由。 3. 流程（每个流程用编号步骤写，可以配 Mermaid 图）： - 日常开发一个功能； - 发布一个版本（如何打标签、版本号规则）； - 线上紧急修复，修复如何回到其他分支，避免下次发布时问题重现； - 如果要同时维护多个版本，修复如何同步到各个版本。 4. 环境与分支的对应关系：哪个分支部署到哪个环境，自动还是手动。 5. 配套：提交信息规范、合并请求模板的要点、需要在托管平台上开启的设置。 6. 从现状迁移到新流程的步骤，以及过渡期的注意事项。 规范部分写成可以直接放进团队知识库的格式。
高亮处换成你自己的内容：[如 8 个开发、2 个测试]、[如每周一次、每天多次、按版本每月一次]、[产品形态]、[如开发、测试、预发、生产]、[如 GitLab + GitLab CI]、[如功能分支存活一个月，合并冲突严重]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[发布频率] 和 [产品形态] 是选择分支模型的决定因素。每天多次部署的 Web 服务适合简单的模型（主干或 GitHub Flow）；需要应用商店审核、或要同时给不同客户维护多个版本的产品，才需要发布分支这类更重的结构。
常见坑：
- 照搬 Git Flow，结果小团队维护 develop、release、master 多条长期分支，流程繁琐，合并总出错。模型的复杂度要和发布方式匹配。
- 功能分支存活太久（几周甚至几个月），合并时冲突巨大。分支越短命越好，大功能可以拆小或者用功能开关先合入主干。
- 热修复只合进了生产分支，没有合回开发分支，下个版本上线后问题又出现了。
追问技巧：追问「把这份规范里需要在代码托管平台上配置的项列成清单，并说明在哪里设置」，或者「写一个合并请求模板」。
示例输出
示例，仅供参考（推荐方案节选：10 人团队，Web 服务每周发布）
推荐：GitHub Flow 加发布标签。只有 main 一条长期分支，所有功能通过短期分支合入；每周从 main 打标签发布。
| 分支 | 命名示例 | 存活时间 | 规则 |
|---|---|---|---|
| main | main | 长期 | 禁止直接推送；合并需 1 人评审且 CI 通过 |
| 功能 | feature/PROJ-123-coupon-limit | 不超过 3 天 | 压缩合并到 main |
| 修复 | fix/PROJ-130-price-rounding | 不超过 1 天 | 同上 |
不推荐 Git Flow 的原因：每周发布、只有一个线上版本，不需要单独的 develop 和 release 分支，多一层分支只会增加合并成本。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～