Git多人合作及分支管理规范

前置工作：git提交的命名规范

规范的基本格式如下：

<类型>[可选 作用域]: <描述>

1. 提交类型 (Type)

规范的提交类型如下：

• feat：新功能（Feature） 。当提交引入一个新的功能时使用。这通常会导致 MINOR 版本号增加。
• fix：错误修复（Bug fix） 。当提交修复了一个 bug 时使用。这通常会导致 PATCH 版本号增加。
• docs：文档（Documentation） 。只修改了文档，如 README.md、CHANGELOG.md 等。
• style：格式（Formatting） 。修改了代码的格式，但不影响代码逻辑（例如空格、分号、缩进等）。注意：不是 CSS 样式！
• refactor：重构（Refactoring） 。既不是修复 bug 也不是添加新功能的代码更改。是代码结构上的优化，不影响行为。
• perf：性能优化（Performance） 。提高性能的代码更改。
• test：测试（Tests） 。添加或修改测试用例，不影响生产代码。
• build：构建系统（Build） 。影响构建系统或外部依赖的更改（例如：Webpack、Rollup、npm、Gulp 等）。
• ci：持续集成（Continuous Integration） 。对 CI 配置文件和脚本的更改（例如：GitHub Actions、GitLab CI、Travis、Jenkins 等）。
• chore：杂项（Chore） 。其他不修改源代码或测试文件的琐碎更改（例如：更新脚手架工具、更改配置文件等）。
• revert：回滚（Revert） 。回滚先前的某个提交。

2. 作用域 (Scope) - 可选

用于说明提交影响的范围，最好是一个名词。这个范围可以是项目中的任何一个模块或文件。 例如

• feat(api): 添加用户登录接口
• fix(ui): 修复按钮点击无效的问题
• refactor(auth): 重构认证逻辑

3. 描述 (Description)

对更改内容的简短描述。

一、核心分支管理策略

常见的分支模型主要有三种：Git Flow、GitHub Flow 和 GitLab Flow。团队可以根据项目类型（如是否需要长期维护多个版本、发布频率等）选择合适的模型。

1. Git Flow (功能驱动)

这是一种相对复杂但功能完备的模型，非常适合有固定发布周期、需要维护多个历史版本（例如：v1.x, v2.x）的项目。

• 主要分支（长期存在） ：

  • main / master： 主分支。代码状态永远与生产环境（Production）一致，是最稳定的分支。只能通过合并来自 release 或 hotfix 的分支来更新。
  • develop： 开发分支。包含了所有开发完成、即将进入下一个发布版本的功能代码，是功能集成的分支。通常比 main 分支要超前。

• 辅助分支（临时存在，用完即删） ：

  • feature/*： 功能分支。从 develop 分支拉取，用于开发新功能。完成后合并回 develop 分支。

    • 命名规范：feature/user-authentication, feature/add-payment-api

  • release/*： 发布分支。当 develop 分支的功能足够发布一个新版本时，从 develop 拉出。用于最后的bug修复、版本号设置等准备工作。测试和修复在此分支进行，不再添加新功能。准备就绪后，合并到 main 和 develop。

    • 命名规范：release/v1.2.0

  • hotfix/*： 热修复分支。从 main 分支拉取，用于紧急修复生产环境的Bug。修复完成后，必须同时合并回 main 和 develop 分支，以确保修复已应用。

    • 命名规范：hotfix/critical-security-patch

工作流程：

graph LR
    A[feature/*] --合并--> B(develop)
    B --准备发布--> C[release/*]
    C --测试完成--> D{main/master}
    C --修复也合并--> B
    D --出现Bug--> E[hotfix/*]
    E --修复完成--> D
    E --修复完成--> B

---

2. GitHub Flow (简化高效)

由 GitHub 倡导，非常强调持续集成和持续部署（CI/CD），适合发布频繁的产品。

• 核心思想：只有一个长期分支 main，它永远是可部署的。

• 流程：

  1. 需要新功能或修复时，从 main 拉出一个新的功能分支（如 feat_xx）。
  2. 在该分支上进行提交，并频繁地推送到远程仓库。
  3. 需要审查或帮助时，创建 Pull Request (PR) 。
  4. 持续在自测环境部署和测试该分支。
  5. 通过代码评审后，合并 PR 到 main。
  6. 立即将 main 分支部署到生产环境。

特点：简单、快速，依赖自动化测试和部署流程。

---

3. GitLab Flow (带预发布环境分支的增强流)

在 GitHub Flow 的基础上，增加了对不同环境（如 staging, production）的支持，是两者的一个折中方案。

• 核心分支：

  • main： 对应预发布环境（Staging）。
  • production： 对应生产环境。只有当 main 分支在预发布环境测试通过后，才通过合并或 CI/CD 流水线自动将 main 的代码同步到 production。

• 流程：同样是基于功能分支和 Merge Request (MR)，但代码流向是 feature -> main (staging) -> production，更清晰地反映了代码在不同环境的推进过程。

二、合并规范 (Merge Strategies)

合并代码不仅仅是 git merge 这么简单，选择正确的合并方式对历史记录的清晰度至关重要。

1. 本地代码提交到远端分支，强制使用rebase方式

   • 禁止使用merge方式： 此方式会生成多余的merge记录，污染远端代码
   • 使用rebase模式： 可以让本地代码的提交直接追加到远端记录的后面，保持时间线的相对干净

2. 创建 Pull Request / Merge Request (PR/MR)

   • 禁止直接向 main, develop 等保护分支进行 git push。
   • 所有代码合并必须通过 PR/MR 进行，这是进行代码审查（Code Review）  的基础。
   • PR/MR 必须由其他成员（非作者）审核批准（Approve）后才能合并。

三、最佳实践总结

1. 保护主分支：在 GitLab/GitHub 中设置 main, develop 为保护分支，禁止直接推送，强制通过 PR/MR。
2. 代码审查：PR/MR 是强制流程，不是可选项。至少需要一名其他成员的 Review 和 Approve。
3. 标题清晰：分支、PR 的命名要清晰表达意图，例如：feat_add_user_login, fix(api): resolve null pointer exception。
4. 频繁集成：频繁地从主分支拉取最新代码（git rebase main）到你的功能分支，减少冲突的规模和难度。
5. 原子化提交：一次提交只做一件事，提交信息按上面的约定规范，如feat:xx、fix:xx等
6. CI/CD 集成：确保每个 PR/MR 在合并前都必须通过所有的自动化测试（CI流水线），保证代码质量。
7. 及时删除已合并的分支：保持仓库分支列表的整洁。

如何选择？

• 传统软件/嵌入式/有版本维护需求：选择 Git Flow。
• Web应用/SaaS/持续部署：选择 GitHub Flow 或 GitLab Flow。
• 大多数团队：可以从 GitHub Flow 或简化的 GitLab Flow 开始，它们更现代、更简单。

最终，没有绝对正确的规范，最适合你团队和项目的就是最好的。关键在于全体成员达成共识并严格遵守。