如何制定团队Git开发协作规范指引？

团队 Git 开发协作规范指引 一、文档目的 统一团队 Git 分支管理、代码提交、合并及发布流程，规范多人协作模式，保证代码可追溯、分支清晰、生产环境稳定，降低协作冲突与线上风险。 二、核心分支定义（固定不可修改） 分支名称 类型 作用 权限控制 master 生产稳定分支 存放已上线、可直接部署的生产代码，永远保持稳定 1. 禁止直接提交/推送 2. 仅管理员可合并发布分支 3. 必须打 Tag 固化版本 dev 开发主分支 日常开发核心分支，所有功能、bug 修复最终汇聚于此 1. 禁止直接提交代码 2. 仅通过 PR 合并个人分支 3. 开发人员可拉取、发起合并 release/版本号 发布分支 预发布、测试专用分支（如 release/8.4.0.900） 1. 仅从 dev 合并代码 2. 禁止直接开发 3. 上线后合并 master 并删除 feature/功能名 功能分支 开发新功能使用（个人临时分支） 开发人员自行创建、开发，完成后删除 bugfix/问题编号 缺陷修复分支 修复测试/开发环境 bug 使用（个人临时分支） 开发人员自行创建、开发，完成后删除 hotfix/问题描述 生产紧急修复分支 仅用于线上生产环境紧急 bug修复 仅核心开发创建，必须同步合并到 dev 和 master 三、分支命名规范（强制遵守） 功能分支：feature/xxx（例：feature/user-login、feature/pay-module） bug 修复分支：bugfix/xxx（例：bugfix/1001-login-error、bugfix/2002-pay-fail） 发布分支：release/版本号（例：release/8.4.0.900、release/8.5.0.100） 生产紧急修复：hotfix/xxx（例：hotfix/crash-fix、hotfix/data-error） 四、标准开发流程（日常功能开发） 1. 拉取最新开发代码 每次开发前，必须同步最新 dev 分支代码，避免冲突： # 切换到 dev 分支 git checkout dev # 拉取最新代码 git pull origin dev 2. 创建个人开发分支 禁止直接在 dev 分支开发，必须从最新 dev 拉取个人分支： # 功能开发 git checkout -b feature/xxx # bug 修复 git checkout -b bugfix/xxx 3. 代码提交规范 提交信息清晰明了，格式：类型: 描述 示例： feature: 完成用户登录功能 bugfix: 修复登录验证码失效问题 小功能多次提交，禁止一次性超大提交 4. 发起合并请求（PR/MR） 开发完成后，推送个人分支到远程，发起 PR（合并请求） 合并到 dev 分支： 推送个人分支：git push origin 分支名 在代码仓库（GitLab/GitHub/Gitee）发起合并请求 分配同事/组长进行代码审阅，审阅通过后方可合并 合并完成后，删除本地及远程个人临时分支 五、版本发布流程（预发布→上线→固化） 1. 创建发布分支 从 dev 分支创建发布分支，用于测试、预发布： git checkout dev git pull git checkout -b release/8.4.0.900 git push origin release/8.4.0.900 2. 代码审阅与测试 发布分支仅用于测试、修复发布阻塞问题，禁止新增功能 测试过程中发现 bug，直接在发布分支修复，修复后同步合并回 dev 必须经过代码审阅，确认无问题后才能准备上线 3. 生产环境上线 使用 release/版本号 分支代码部署生产环境，验证上线成功。 4. 合并 master 并固化版本 上线成功后，将发布分支合并到 master 分支（仅管理员操作） 在 master 分支打 Tag 永久固化版本（回滚唯一依据）git checkout master git pull git merge --no-ff release/8.4.0.900 git tag -a v8.4.0.900 -m "生产上线版本 v8.4.0.900" git push origin master --tags 删除远程及本地发布分支，清理分支环境 六、生产环境紧急修复流程 仅用于线上已发布版本出现紧急 bug，禁止常规开发使用： 从 master 分支拉取紧急修复分支：git checkout master git pull git checkout -b hotfix/xxx 修复 bug 并测试通过 先合并到 dev 分支，保证开发代码同步修复 再合并到 master 分支，打新 Tag 上线 合并完成后删除紧急修复分支 七、强制规则与禁忌（红线要求） 禁止直接提交：master、dev 分支禁止直接提交、强制推送代码 禁止跨分支开发：所有个人分支必须从 dev 创建，发布分支必须从 dev 创建 禁止跳过审阅：dev→release、release→master 必须经过代码审阅 禁止保留废弃分支：个人分支、发布分支、修复分支使用完成后必须删除 禁止在发布分支开发功能：发布分支仅用于测试和修复阻塞问题 八、冲突处理规范 合并前先拉取目标分支最新代码，本地解决冲突后再提交 冲突代码必须与相关开发人员确认，禁止随意覆盖他人代码 冲突解决完成后，重新提交并发起审阅 九、版本 Tag 规范 格式：v主版本.次版本.修订号.发布序号 示例：v8.4.0.900、v8.5.0.100 每次合并到 master 必须打 Tag，作为版本回溯、回滚的唯一标识 文档说明 本规范为团队标准 Git 协作流程，所有开发人员必须严格遵守，如有特殊场景需调整，需统一沟通确认后更新文档。