> For the complete documentation index, see [llms.txt](https://tech.banchengyun.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://tech.banchengyun.com/docs/common/git.md).

# git 使用规范

## 1、通过修改配置文件 .gitconfig，此文件一般在个人主目录下（～/），配置如下

* \[user]
* name = `xxxx` #开发者名称
* email = `xxxxxx@163.com` # 邮箱随意

## 2、分支划分如下：（目前开发分支与测试分支暂为一个）

* master：线上分支
* gray：灰度发布分支--有必要时合并，与preview分支代码保持一致
* preview：预发布分支，每次代码上线前必经分支，正式上线后，与线上分支保持绝对一致
* develop：开发测试分支
* feature-xxx：功能分支
* hotfix-xxx：热修复分支，不常驻，当需要热修复时，用于修复线上bug；

## 3、分支命名规范约定如下：

* feature分支命名：feature-xxxx
* hotfix分支命名：hotfix-xxxx

## 4、commit -m 命名规范约定

* feat：新功能（feature）
* fix：修补bug
* docs：文档修改
* style： 不影响代码含义的修改(例如：white-space; 格式化等)
* refactor：重构（即不是新增功能，也不是修改bug的代码变动）
* perf: 提升性能的修改
* test：增加或修改测试
* chore：构建流程或辅助工具的变动

## 5、正常开发流程

* 每个版本都从master分支拉出代码，代码完成后，合并到develop分支进行测试，测试通过后，合并到预发布分支，预发布分支通过后，代码由预发布分支合并到线上分支
* 切出新分支：git fetch origin master:feature-test
* 将新分支推到远程仓库：git push --set-upstream origin feature-test
* 开发完成后，切换到测试分支（develop），合并开发分支代码:git merge feature-test --no-ff -m"XXXXXXXX"
* 测试完成后，切换到预发布分支（preview），合并开发分支代码:git merge feature-test --no-ff -m"XXXXXXXX"
* 预发布用过后，切换到线上分支（master），合并预发布分支代码:git merge preview --no-ff -m"XXXXXXXX"

## 6、线上紧急bug修复

* 从线上分支克隆出来一个热修复分支：git fetch origin master:hotfix-test
* 切换到热修复分支：git checkout hotfix-test
* 修复bug
* 切换到预发布分支：git checkout preview
* 将热修复分支代码合并到预发布分支：git merge hotfix-test --no-ff -m"XXXXXXXX"
* 验证通过后，将代码提交到preview分支线上仓库:git add、commit、pull、push
* 将热修复分支代码合并到测试分支
* 切换到master分支，将热修复分支合并到master分支，将master分支推到线上仓库
* 完成热修复
* 注意一点，合并分支的时候，一定带上–no-ff，它可以保存你之前的分支历史。能够更好的查看合并历史，以及分支状态

## 7、关于冲突

* 首先、开发的时候，尽量每个人负者不通模块，尽量避免冲突场景
* 如果避免不了业务交叉，每完成一个接口或方法，同步一次代码，减少冲突可能性
* 出现冲突，打开冲突文件，确认保留代码（多人编写造成的，需和同事确认，避免勿删），再提交到线上仓库