分支规范
在开发过程中,一般会存在以下几种分支:
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
进行合并,并解决可能发生的冲突。 - 定期清理不再需要的功能分支,完成并合并后删除它们以保持分支列表清晰。
常用分支命令
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/remoteName
Commit 提交规范
-
提交的日志格式
每次git提交日志格式为: 类型:描述
类型:用于说明 commit 的类别,只允许使用下面7个标识。- feat:新功能
- fix:修补bug
- docs:修改文档
- style: 格式化代码结构,没有逻辑上的代码修改
- refactor:重构,即不是新增功能,也不是修改bug的代码变动,比如重命名变量
- test:增加测试代码,单元测试一类的,没有生产代码的变更
- chore:构建过程或辅助工具的变动(不会影响代码运行)
描述:是本次commit的描述,说明白本次提交都干了些啥
例如:
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
更新代码。
远程分支新增一个类,如下
# 目前代码处于feature--xx分支,且都已经本地提交(没提交的可以使用暂存功能) 同步远程库代码变动
$ git fetch origin
# 使用rebase进行代码更新代码
$ git pull origin feature--xx --rebase
备注:
git fetch #拉取代码,需要使用git merge进行合并
git pull #拉取代码,会直接将本地代码更新至远程仓库里面最新的版本
# 也可使用IDEA自带功能(具体不再详述)
场景二:feature--xx
分支代码有了新代码的更新,a要合并代码。
梳理下思路:
feature--xx-a
更新远程分支代码(不更新也行,因为只有a在使用);- 合并
origin/feature-xx
分支代码,有冲突解决冲突,没有冲突将代码push到服务器; - 发起合并。
远程feature-xx
分支新增输出内容
操作步骤
# 假设所有代码已经都提交,无需进行提交或者暂存代码的操作;
$ git checkout feature--xx-a
# 同步远程库代码变动
$ git fetch origin
# 使用rebase进行代码合并(合并上层分支到下层)
$ git rebase origin/feature--xx
# 如果此时有冲突,解决冲突,并将解决完冲突的代码提交,在执行rebase 即可
$ git rebase --continue
合并后如下
# 合并完之后,push代码,push完之后,a的代码已经到远程feature-xx-a分支了
$ git push # 此时,如果需要进行代码审核,发起一个合并请求即可;
# 如果不需要进行代码审核,后续操作就是合并到feature--xx分支
# 切换分支,并更新代码
$ git checkout feature--xx
$ git pull --rebase
# 合并张三分支代码,并推送远程
$ git merge feature--xx-a
# git push --set-upstream origin feature--xx
$ git push
分支使用及发版流程
负责人排定发行版计划,并执行发行版控制,注意前/后端的协同。测试版本可根据开发计划,拆解生产版本任务,组织阶段测试。
提测通过后拉分支继续开发、版本内有bug修复后合到已提交版本重新发版。具体流程如下: