分支规范
在开发过程中，一般会存在以下几种分支：
main分支(master)
master为主分支，也是用于部署生产环境的分支，一般由 dev 以及 fixbug分支合并，任何时间都不能直接修改代码。dev分支
develop 为开发分支，始终保持最新完成以及bug修复后的代码。一般开发新功能时，feature 分支都是基于 dev 分支下创建的。feature-[功能名称/版本信息]
feature为需求分支，以 dev 分支为基础创建 feature 分支。每个开发人员基于feature分支，创建自己的开发分支。fixbug-[bug编号]
线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 fixbug分支，修复完成后，需要合并到 master 分支和 dev 分支。
注意：
- 使用
git pull定期从远程仓库拉取更新并与本地分支同步，避免出现长时间不更新导致合并时产生大量冲突的情况。 - 合并代码前，运行
git fetch获取远程分支最新状态，然后使用git merge或git rebase进行合并，并解决可能发生的冲突。 - 定期清理不再需要的功能分支，完成并合并后删除它们以保持分支列表清晰。
常用分支命令
shell
git branch -r #远程仓库分支
git branch -a #所有分支列表
git branch #新分支名称
git checkout branchName #切换分支
#创建分支并切换
git checkout -b branchName
#删除本地分支，当分支被推送并合并到远程分支后-d才会删除本地分支
git branch -d localBranchName
#删除远程分支
git push origin --delete remoteBranchName
#推送本地分支到远程分支（远程暂时无对应分支）
git push origin localBranch:remoteBranch
#拉取远程分支到本地（在本地创建分支并自动切换到新分支并且与远程分支建立映射关系）
git checkout -b localBranch origin/remoteNameCommit 提交规范
-
提交的日志格式
每次git提交日志格式为： 类型:描述
类型：用于说明 commit 的类别，只允许使用下面7个标识。- feat：新功能
- fix：修补bug
- docs：修改文档
- style： 格式化代码结构，没有逻辑上的代码修改
- refactor：重构，即不是新增功能，也不是修改bug的代码变动，比如重命名变量
- test：增加测试代码，单元测试一类的，没有生产代码的变更
- chore：构建过程或辅助工具的变动（不会影响代码运行）
描述 ：是本次commit的描述，说明白本次提交都干了些啥
例如：
shell
git commit -m "feat: 新增用户详情页接口"
git commit -m "fix: 修复用户注册时电话号码校验逻辑问题"
git commit -m "docs: 新增项目Readme 文档"- 提交频率
- 提交粒度按照功能点进行提交，切记不要一直不提交，积攒一大堆代码再提交；
更新、合并规范
原则：
- 下游分支更新上游分支代码用
rebase； - 上游分支合并下游分支代码用
merge； - 更新本分支代码用
--rebase(如果本分支有多人共同使用开发的时候)；
这样可以消除自动产生的无用merge记录，有利于后续查看开发记录。
下游分支在更新上游分支代码的时候，如果使用
merge,会产生一条无用的合并记录，比较影响查看历史，使用rebase则不会。
分场景介绍
目前有个xx需求，由a、b两名同事进行开发分支说明（建立个人开发分支是为了方便做代码review）
master：主分支dev：测试分支Feature--xx：订单详情需求分支Feature--xx-a：订单详情a开发分支Feature--xx-b：订单详情b开发分支
master主分支内容
当前所有分支都基于master分支进行创建，内容与master分支一致。
场景一 ：feature--xx分支代码有个更新，本地feature--xx更新代码。
远程分支新增一个类，如下
shell
# 目前代码处于feature--xx分支，且都已经本地提交（没提交的可以使用暂存功能） 同步远程库代码变动
$ git fetch origin
# 使用rebase进行代码更新代码
$ git pull origin feature--xx --rebase
备注：
shell
git fetch #拉取代码，需要使用git merge进行合并
git pull #拉取代码，会直接将本地代码更新至远程仓库里面最新的版本
# 也可使用IDEA自带功能(具体不再详述)场景二 ：feature--xx分支代码有了新代码的更新，a要合并代码。
梳理下思路：
feature--xx-a更新远程分支代码(不更新也行，因为只有a在使用)；- 合并
origin/feature-xx分支代码，有冲突解决冲突，没有冲突将代码push到服务器； - 发起合并。
远程feature-xx分支新增输出内容
操作步骤
shell
# 假设所有代码已经都提交，无需进行提交或者暂存代码的操作；
$ git checkout feature--xx-a
# 同步远程库代码变动
$ git fetch origin
# 使用rebase进行代码合并（合并上层分支到下层）
$ git rebase origin/feature--xx
# 如果此时有冲突，解决冲突，并将解决完冲突的代码提交，在执行rebase 即可
$ git rebase --continue 合并后如下
bash
# 合并完之后，push代码，push完之后，a的代码已经到远程feature-xx-a分支了
$ git push
# 此时，如果需要进行代码审核，发起一个合并请求即可；
# 如果不需要进行代码审核，后续操作就是合并到feature--xx分支
# 切换分支,并更新代码
$ git checkout feature--xx 
bash
$ git pull --rebase
# 合并张三分支代码，并推送远程
$ git merge feature--xx-a 
bash
# git push --set-upstream origin feature--xx
$ git push分支使用及发版流程
负责人排定发行版计划，并执行发行版控制，注意前/后端的协同。测试版本可根据开发计划，拆解生产版本任务，组织阶段测试。
提测通过后拉分支继续开发、版本内有bug修复后合到已提交版本重新发版。具体流程如下：