规范分类

image.png

版本规范

版本号可按以下规则递增：
主版本号（MAJOR）：当做了不兼容的 API 修改。
次版本号（MINOR）：当做了向下兼容的功能性新增及修改。这里有个不成文的约定需要你注意，偶数为稳定版本，奇数为开发版本。
修订号（PATCH）：当做了向下兼容的问题修正。
image.png

Commit规范

image.png工作流设计

Git 的4 种开发模式

  1. 集中式工作流：开发者直接在本地 master 分支开发代码，开发完成后 push 到远端仓库 master 分支。
  2. 功能分支工作流：开发者基于 master 分支创建一个新分支，在新分支进行开发，开发完成后合并到远端仓库 master 分支。

  3. Git Flow 工作流：Git Flow 工作流为不同的分支分配一个明确的角色，并定义分支之间什么时候、如何进行交互，比较适合大型项目的开发。

    Git Flow 的 5 种分支Git Flow 中定义了 5 种分支，分别是 master、develop、feature、release 和 hotfix。其中，master 和 develop 为常驻分支，其他为非常驻分支，不同的研发阶段会用到不同的分支。这 5 种分支的详细介绍见下表：
    image.png
    bug紧急修复使用案例 ```git

$ git stash # 1. 开发工作只完成了一半，还不想提交，可以临时保存修改至堆栈区 $ git checkout -b hotfix/print-error master # 2. 从 master 建立 hotfix 分支 $ vi main.go # 3. 修复 bug，callmainfunction -> call main function $ git commit -a -m ‘fix print message error bug’ # 4. 提交修复 $ git checkout develop # 5. 切换到 develop 分支 $ git merge —no-ff hotfix/print-error # 6. 把 hotfix 分支合并到 develop 分支 $ git checkout master # 7. 切换到 master 分支 $ git merge —no-ff hotfix/print-error # 8. 把 hotfix 分支合并到 master $ git tag -a v0.9.1 -m “fix log bug” # 9. master 分支打 tag $ go build -v . # 10. 编译代码，并将编译好的二进制更新到生产环境 $ git branch -d hotfix/print-error # 11. 修复好后，删除 hotfix/xxx 分支 $ git checkout feature/print-hello-world # 12. 切换到开发分支下 $ git merge —no-ff develop # 13. 因为 develop 有更新，这里最好同步更新下 $ git stash pop # 14. 恢复到修复前的工作状态 ```

  1. Forking 工作流：开发者先 fork 项目到个人仓库，在个人仓库完成开发后，提交 pull request 到目标远程仓库，远程仓库 review 后，合并 pull request 到 master 分支。

集中式工作流是最早的 Git 工作流，功能分支工作流以集中式工作流为基础，Git Flow 工作流又是以功能分支工作流为基础，Forking 工作流在 Git Flow 工作流基础上，解耦了个人远端仓库和项目远端仓库。
image.png