Git 使用规范

branch / 分支规范

分支命名

• master / main 分支

1. / main 为代码主分支，是用于直接部署到生产环境的分支，需要确保稳定。maintainer, developer均不可以直接在此分支上进行修改代码，push等操作。

• develop 分支

1. 分支为开发分支，始终保持最新完成以及bug修复后的代码。只允许maintainer在此分支上进行直接修改代码，push等操作。

• feature 分支
  此分支为开发新功能时，以 develop 分支为基础创建的分支。

分支命名规则：以feature/开头，后接新功能的模块，如：feature/cart。

• fix 分支
  此分支为修复bug时创建的分支，命名规则与feature分支类似，在master/main分支或者develop分支代码出现bug需要修复时以其为基础创建。如果此bug在master/main分支与develop分支中都存在，则两个分支都需要合并创建的分支。

注意事项

• 每当要修改代码时，请以develop分支为基础创建分支。修改完成后一定要经过测试，再合并到develop分支，避免别人从develop分支拉下代码后报错。
• 本地的分支要多提交，分小功能提交，最好不要一次提交一大堆功能。
• 每天第一件事就是及时更新 develop 分支内容到本地分支。

示例

## 跳转到 develop 分支
$ git checkout develop
## 拉取远程代码库中develop分支最新的代码
$ git pull
## 创建分支并直接跳转到此分支
$ git checkout -b "feature/add-confirm-for-logout-button"
## 修改代码, commit后push到远程代码库
$ git push --set-upstream origin feature/add-confirm-for-logout-button

之后就可以在网站上发起merge request来申请合并

merge / 分支合并规则

• 在将分支推送到远程代码库时并发起mergel request时，如果此repo存在code viewer，需要@code viewer 进行代码审阅。
• 如果此次merge request由maintainer发起，可以直接合并进目标分支。如果是由developer发起，则需要maintainer来进行合并操作。
• 发起merge request时，请勾选squash commits以及delete source branch这二个选项来压缩commits和自动删除merge后残留的分支。

commit / 提交规范

代码的 commit 使用conventional commits规范，务必使用conventional commits规范中提到的工具， 如 cz-cli(node) , git-changelog-lib(java)来优化 commit 效率, converntial commits 规范如下：

每次提交代码需要写commit messsage（提交信息）:

$ git commit -m [commit message]

commit message 应该清晰明了，说明本次提交的目的。
可以将提交信息分为三个部分：

<type>/(<scope>):<subject>

例子：

docs(cli): add screenshot of add-commit

type类型

• feat: feature, 新功能
• fix: bug的修复
• docs: 文档相关的改动
• style: 格式，如format了代码，增加空行等操作
• refactor: 重构
• test: 测试的改动
• chore: 构建工具或者辅助工具的变动

scope

说明本次commit改动的范围，如文件名，模块，路由等。

subject

概述本次的改动。

TAG & PUBLISH / 标签及发布规范

给repo中的某个commit打上tag以表示重要性，一般使用tag功能来标记软件的发布节点或版本，如v1.0.1, v0.9.1-beta
eg:

$ git tag -a v1.0.1 -m "my version 1.0.1"

如果打上的tag表示发布的版本，标签命名应遵守semver版本号命名规范。

semver版本号命名规范

软件的版本号命名分为三个部分：<主版本号>.<次版本号>.<修订号>，如1.0.1, 0.9.2。
先行版本号可以加到后面作为延伸，如1.0.1-alpha, 1.1.2-rc.2。
版本号递增规则：

• 主版本号：当你做了不兼容的 API 修改，
• 次版本号：当你做了向下兼容的功能性新增，
• 修订号：当你做了向下兼容的问题修正。

先行版本号

• alpha: 内部版本
• beta: 测试版
• rc: 即将作为正式版发布
• release: 正式版本

对于版本号相关的疑问，请参考semver的文档。