以下内容基于 Git Flow 分支管理策略。

Git Flow 最开始是由 Vincent Driessen 发行并广受欢迎，这个模型是在 2010 年构思出来的，而现在距今已有 10 多年了，而 Git 本身才诞生不久。在过去的十年中，Git Flow 在许多软件团队中非常流行

分支命名规范

  • master 分支：master 分支只有一个，名称即为 master。(GitHub 现在叫 main)
  • develop 分支：develop 分支只有一个，名称即为 develop
  • feature 分支：feature/<功能名>，例如：feature/login，以便其他人可以看到你的工作
  • hotfix 分支：hotfix/日期，例如：hotfix/0104

分支说明

  • master || main 分支：存储正式发布的产品，master || main 分支上的产品要求随时处于可部署状态。master || main 分支只能通过与其他分支合并来更新内容，禁止直接在 master || main 分支进行修改。

  • develop 分支：汇总开发者完成的工作成果，develop 分支上的产品可以是缺失功能模块的半成品，但是已有的功能模块不能是半成品。develop 分支只能通过与其他分支合并来更新内容，禁止直接在 develop 分支进行修改。

  • feature 分支：当要开发新功能时，从 master 分支创建一个新的 feature 分支，并在 feature 分支上进行开发。开发完成后，需要将该 feature 分支合并到 develop 分支，最后删除该 feature 分支。

  • release 分支：当 develop 分支上的项目准备发布时，从 develop 分支上创建一个新的 release 分支，新建的 release 分支只能进行质量测试、bug 修复、文档生成等面向发布的任务，不能再添加功能。这一系列发布任务完成后，需要将 release 分支合并到 master 分支上，并根据版本号为 master 分支添加 tag，然后将 release 分支创建以来的修改合并回 develop 分支，最后删除 release 分支。

  • hotfix 分支：当 master 分支中的产品出现需要立即修复的 bug 时，从 master 分支上创建一个新的 hotfix 分支，并在 hotfix 分支上进行 BUG 修复。修复完成后，需要将 hotfix 分支合并到 master 分支和 develop 分支，并为 master 分支添加新的版本号 tag，最后删除 hotfix 分支。

提交信息规范

提交信息应该描述“做了什么”和“这么做的原因”，必要时还可以加上“造成的影响”，主要由 3 个部分组成：Header、Body 和 Footer。

Header 部分只有 1 行，格式为: 。

type 用于说明提交的类型，共有下面几个候选值：

  • feat：新功能（feature）
  • fix：问题修复
  • docs：文档
  • style：调整格式（不影响代码运行）
  • refactor：重构
  • test：增加测试
  • chore：构建过程或辅助工具的变动
  • revert：撤销以前的提交
  • scope: 用于说明提交的影响范围，内容根据具体项目而定
  • perf: 性能优化

subject 用于概括提交内容。

Body

一般不写

一般不写

demo

这样做起来的好处，一个项目下：

  • 对于分支，每个人在做什么，我看分支就清楚。
  • 对于修改内容，看前缀就知道这个文件改动了什么。
  • 对于版本迭代，看 Tag 都上线了什么内容。

todo: 前端项目管理实例