docs: 添加 git flow 图片

docs/02.md

@@ -345,21 +345,37 @@ extends: [
 当然，代码审查也是有缺点的：一是代码审查非常耗时，二是有可能引发团队成员争吵。据我了解，目前国内很多开发团队都没有代码审查，包括很多大厂。
 
 个人建议在找工作时，可以询问一下对方团队是否有测试规范、测试流程、代码审查等。如果同时拥有以上几点，说明是一个靠谱的团队，可以优先选择。
-## git 规范
-git 规范一般包括两点：分支管理规范和 git commit 规范。
+## Git
+Git 规范一般包括：Git Flow 规范、分支管理规范和 git commit 规范。
+### Git Flow 规范
+Git Flow 规范网上已经有非常多的文章去讲解了，这里也不再细说，贴一个我比较常用的 Git Flow 流程图，和主流常用的大同小异。
+
+![](./img/git-flow.png)
+
+[点击查看大图](https://woai3c.github.io/introduction-to-front-end-engineering/assets/img/git-flow.e5218e44.png)
 ### 分支管理规范
-一个项目可以创建两个分支：master 和 dev。master 对应线上分支，不能直接在 master 分支上写代码，开发时需要从 master 上拉一个 dev 分支进行开发。
+#### 命名
+分支命名以 `feature/xx-xx` `fix/xx-xx` 的格式命名，中间用短横线 `-` 连接。
+#### 分支管理
+项目需要根据环境的不同创建对应的分支：
+* master（线上环境）
+* develop（开发环境）
+* test（测试环境）
+* feature/xxx（功能分支）
+* fix/xxx（修复分支）
+* 其他...
 
 #### 开发新功能
-当团队成员开发新功能时，需要从 dev 上拉一个 `feature-功能名称-开发姓名` 分支进行开发，例如：`feature-login-tgz`。开发完成后需要合并回 dev 分支。
+当团队成员开发新功能时，需要从 `master` 分支上拉一个 `feature/功能名称-开发姓名` 分支进行开发，例如：`feature/login-tgz`。开发完成后需要合并到 `develop` 分支进行部署测试。
 
 #### 修改 bug
-当团队成员修改 bug 时，需要从有 bug 的分支（环境）上拉一个 `bug-功能名称-开发姓名` 分支进行修复，例如：`bug-login-tgz`。修复完成后需要合并回原来出现 bug 的分支。
+当团队成员修改线上 bug 时，需要从 `master` 分支拉一个 `fix/功能名称-bug号/bug现象` 分支进行修复，例如：`fix/login-404`。
+修复完成并通过测试后再合并到 `master` 分支进行部署。
 
-以 `feature` 或 `bug` 开始的分支都属于临时分支，在通过测试并上线后需要将临时分支进行删除。避免 git 上出现太多无用的分支。
+以 `feature` 或 `fix` 开始的分支都属于临时分支，在通过测试并上线后需要将临时分支进行删除。避免 git 上出现太多无用的分支。
 
 #### 合并分支
-在将一个分支合并到另一个分支时（例如将 `feature-*` 合并到 dev），需要查看自己的新分支中有没有多个重复提交或意义不明的 commit。如果有，则需要对它们进行合并（git rebase）。示例：
+在将一个分支合并到另一个分支时（例如将 `feature/*` 合并到 develop），需要查看自己的新分支中有没有多个重复提交或意义不明的 commit。如果有，则需要对它们进行合并（git rebase）。示例：
 ```bash
 # 这两个 commit 可以合并成一个
 chore: 修改按钮文字
@@ -368,20 +384,13 @@ chore: 修改按钮样式
 # 合并后
 chore: 修改按钮样式及文字
 ```
-**注意**：在将 `feature-*` 合并到 dev 时，需要先将 dev 分支合并到 `feature-*` 分支，然后再将 `feature-*` 合并到 dev 分支，避免出现代码冲突的情况。同理，合并 `bug-*` 分支也一样。
-
-#### 部署
-当 dev 分支通过测试后，就可以合并到 master 进行发布了。
-
-#### 发布时可能出现的意外情况
-举个例子，假设程序要新增 a、b 两个功能，我们的操作流程是这样的：
-1. 从 dev 分支拉两个新分支 `feature-a-tgz`、`feature-b-tgz`。
-2. 开发完成合并回 dev。
-3. dev 测试完毕后，合并到 master 进行发布。
-
-如果这时突然被告知 b 功能不上，只上 a 功能。我们可以将 `feature-a-tgz` 分支重新部署到测试环境，这样就不用做任何的代码回滚。只要 `feature-a-tgz` 分支测试通过就可以直接合到 master 进行线上发布。
+**注意**，在将分支合并到另一分支前，例如将 `feature/*` 合并到 `develop`。需要先拉取 `develop` 的最新更新，然后回到 `feature/*`，执行 `git rebase develop` 操作，再提交，最后提合并分支操作。
+#### 标签备份
+每次代码上线时，均要对当前的线上环境分支（例如 master）进行打标签处理，用作备份。当线上环境出现问题时，可以快速回滚。标签命名有两种方式：
+1. 版本号命名，适合移动端 APP 或组件库
+2. 用时间+当天发布次数命名，例如 20230319-1，这种命名方式一般用于业务项目。
 
-### git commit 规范
+### Git Commit Message 规范
 git 在每次提交时，都需要填写 commit message。
 ```bash
 git commit -m 'this is a test'