大家好，我是厚厚。
好久不见，转眼已经来到了2022年，疫情还没有消散……
不过我们的生活早已经恢复正常
新的一年，Flag还是要立的，万一都完成了呢？
一起加油呀！
最近在项目中发现，有些小伙伴在使用Git的时候，不是那么的规范，抽空整理了一波，希望可以帮到你。
文章主要包含：分支规范、提交合并规范、分支使用流程等。
划重点：提交合并你还在用merge吗？rebase了解一下。
一、分支规范
在开发过程中，一般会存在以下几种分支：
main分支(master)
master为主分支，也是用于部署生产环境的分支，一般由 dev 以及 fixbug分支合并，任何时间都不能直接修改代码。
dev分支
develop 为开发分支，始终保持最新完成以及bug修复后的代码。一般开发新功能时，feature 分支都是基于 dev 分支下创建的。
feature-[功能名称/版本信息]
feature为需求分支，以 dev 分支为基础创建 feature 分支。每个开发人员基于feature分支，创建自己的开发分支。
fixbug-[bug编号]
线上出现紧急问题时，需要及时修复，以 master 分支为基线，创建 fixbug分支，修复完成后，需要合并到 master 分支和 dev 分支。
二、Commit 提交规范
2.1 提交的日志格式
每次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 文档"
2.2 提交频率
- 提交粒度按照功能点进行提交，切记不要一直不提交，积攒一大堆代码再提交；
- 在push之前压缩那些临时的或者无意义的commit；
切记压缩多个commit，只能对自己的提交进行压缩，不要操作别人的提交，不然可能会被同事追着打
- 命令行方式
# 找到需要合并的commit；例如：想对最近4次提交进行合并，该如何操作呢？
# -i 等价于 --interactive
$ git rebase -i HEAD~4
# 或者 通过git log 找到最近4次提交的父类提交，也就是第5次提交的commitId进行合并操作
$ git log
$ git rebase -i 6ecc2741a2337d6b50f2c35ba877aa040eea3531
# 接下来会进入vi 操作，会自动列出需要合并的提交，结构是这样：操作 commitId 提交备注 例如：
# pick f77f9da list branch update two
# pick ff65dd9 feat: list branch update three and four
# 解释一下常用的操作：pick: 保留这次提交；squash：保留这个commit，但是会将这个commit融入到上一个commit；fixup：同squash，但是会丢弃掉log message
# 修改完之后，保存（:wq）
# 保存之后，紧接着进入修改commit 的vi操作。
# 修改完commit之后，保存（:wq）,完工
# 在使用git log 就可以看到之前4个提交日志，只能看到两个了。
pick：保留该commit（缩写：p）
reword：保留该commit，修改该commit的注释（缩写：r）
edit：保留该commit，rebase时会暂停，允许你修改这个commit（缩写：e）
squash：会将当前commit与上一个commit合并(缩写：s)
fixup：与squash相同，但不会保存当前commit的提交注释信息(缩写：f)
exec：执行其他shell命令（缩写：x）
drop：丢弃该次提交（缩写：d）
- IntelliJ IDEA开发工具自带方式
2.3 更新、合并规范
原则：
① 下游分支更新上游分支代码用rebase；
② 上游分支合并下游分支代码用merge；
③ 更新本分支代码用--rebase (如果本分支有多人共同使用开发的时候)；
这样可以消除自动产生的无用merge记录，有利于后续查看开发记录。
下游分支在更新上游分支代码的时候，如果使用
merge,会产生一条无用的合并记录，比较影响查看历史，使用rebase则不会。
下面分场景说明应该如何操作，目前有个xx需求，由a、b两名同学进行开发分支说明（建立个人开发分支是为了方便做代码review）：
-
master：主分支 -
dev：测试分支 -
feature-xx：订单详情需求分支 -
feature-xx-a：订单详情a开发分支 -
feature-xx-b：订单详情b开发分支
场景一：feature-xx分支代码有个更新，本地feature-xx更新代码。
c、d两位同学共同在
feature-xx分支上开发，其中一个push了代码，另外一个更新。
- 命令行方式
# 目前代码处于feature-xx分支，且都已经本地提交（没提交的可以使用暂存功能）
同步远程库代码变动
$ git fetch origin
# 使用rebase进行代码更新代码
$ git pull origin feature-xx --rebase
- IntelliJ IDEA开发工具自带方式
场景二：feature-xx分支代码有了新代码的更新，a要合并代码。
梳理下思路：
①
feature-xx-a更新远程分支代码(不更新也行，因为只有a在使用)；② 合并
origin/feature-xx分支代码，有冲突解决冲突，没有冲突将代码push到服务器；③ 发起合并。
- 命令行方式
# 假设所有代码已经都提交，无需进行提交或者暂存代码的操作；
$ 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
- IntelliJ IDEA开发工具自带方式
步骤①参考场景一，这里只展示一下步骤②应该如何操作。
2.4 分支使用及发版流程
负责人排定发版计划，并执行发版控制，注意前/后端的协同。测试版本可根据开发计划，拆解生产版本任务，组织阶段测试。
提测冒烟通过后拉分支继续开发、版本内有bug修复后合到已提交版本重新发版。具体流程如下：