由于网上的常用命令文章很多，所以本文不给出命令和解释，只从实际使用流程和理解入手，并针对使用附上命令。如需常用命令可以查看如下网址。

…

一、工作流

在项目中，master分支为线上分支 release为beta分支 dev为开发分支。

二、拉取远程分支

我们在开发自己的特性或者修复缺陷时，需要拉取远程的master分支，基于master分支切一个自己的开发分支。

git pull master
或
git fetch master
master merge origin/master

解释：pull默认就是执行了fetch 和 merge

fetch：拉取的代码是更新了origin/master 不会对工作区和暂存区做出影响

merge：执行了merge之后，会把origin/master合并到本地的master上

三、切自己的开发分支

1. 特性分支一般命名为 feature-XX-XX 缺陷修复为bugfix-XX-XX

基于当前分支切新分支
git branch feature-XX / bugfix-XX  // 新建分支不切换不建立远程连接
git checkout -b feature-XX / bugfix-XX // 切换并且新建分支
git checkout feature-XX / bugfix-XX  // 切换分支 如果本地没有而远程有该分支则拉取远程到本地并且建立远程连接

建立远程连接就是和origin/XXX 的分支建立连接 在pull 或者 push 无需指定远程分支

2. 拉取完开始开发，并且生成一些自己的提交，同时可以远程同步自己最新的提交

git add . // 添加修改的代码到暂存区
git commit -m 'feat/fix: XXXX'  // 生成一次提交
git push // 提交到建立链接的远程分支 
git branch --set-upstream-to=origin/feature-branch feature-branch // 如果没有建立连接则执行该命名建立连接
或
git push -u origin/feature-branch （不推荐）

3. 如果开发过程中有新版本发布，

// 拉取最新的master代码 如果存在工作区和暂存区的代码可以先stash,等合并完最新代码后在pop回来
git stash
git rebase master // 在rebase之前建议新建一个分支用于备份
// 如果遇到冲突，解完后需要加入暂存区 然后继续
git rebase --abort  // 取消本次rebase  
git rebase --continue // 解决完冲突后继续rebase
git stash pop

建议: 在此时进行一次变基更新（修订：不一定，会和dev冲突）如果遇到冲突，不知道咋解需要找到写代码的人协商解决。

如果此时你需要提交，会发现落后远程分支又领先远程分支，那是因为变基导致，确保代码没问题可以直接git push --force

四、合并自己的开发分支到sit

1.保证当前dev分支为最新分支,然后合并自己的分支并推送远端

当前在dev分支
git pull
git merge feature-XXX/bugfix-XXX // 将自己的代码合到dev分支
修订：==========================2024年8月9日
由于本地分支可能领先于dev某些提交，所以经验所得用cherry-pick新提交到dev上
git cherry-pick hash[commit]
此时应该在本地看一下dev的代码能否成功编译运行
git push // 推送到远端

如果遇到冲突，可以解决的解决，不能解决的找人，解完git add .再git commit -m xxx如果没有冲突则直接可以git push

2.通过自动化或者手动部署到sit环境

sit是开发环境，staging是release环境，如果要合并到release需要提cr。prod是生产环境。

补充：merge和rebase

可查看如下文章看详细原理

dingjingmaster.github.io/2022/05/000…

git rebase 和 git merge 这两个命令旨在将更改代码从一个分支合并到另一个分支，只是两者合并方式不一样。

git rebase master feature-XX-XX, 会把 feature-XX-XX 合并到 master 的头部, 相当于把feature-XX-XX上的提交，按顺序添加到master后面，任何一个提交如果出现冲突，都需要解决。会出现要解决很多冲突的情况，解决完需要git add . 再git rebase --continue，最后解决完全部冲突即可后续操作。

git merge feature-XX-XX dev , 会把 feature-XX-XX 所有历史提交生成一个新的提交，添加到dev的头部。此时如果有冲突只需要解决一次冲突，然后git add . 即可后续操作

五、上beta和上线

当你在测试环境测完没问题后，那就可以上release。如果没有release分支则基于master拉一个release分支。

新人建议： 基于自己的开发分支切一个beta分支用于操作，保留原始开发分支以防万一。

1.拉取最近master合并到自己的分支

git checkout release-XXXX
git rebase master
git rebase release-XXXX (建议)
如果有冲突则解
git add .
git commit -m ''
git push // 推送到远端
然后提cr到release-XXXX分支

2.cr合并出现冲突

此时需要重新拉取最新的release-XXXX，然后rebase解完冲突，再次提交cr

测试在beta环境回测，没问题则继续

3.上线阶段，跟车或者自己发车

如果是跟车的话，则和司机说自己的改动点，跟着发车就好

如果自己是司机，在变更群发出发布通告，然后提交cr从release到master分支，审核通过后合并到master分支

本地拉取最新的master分支，打包打tag,发布即可

六、提交规范 Conventional Commits

1.原子提交： 每次提交应该尽可能是原子的，不可拆分。

2.功能完整： 提交应该包含完成一个完整的功能或 bug 修复，回滚可以回到某个稳定版本

3.修饰信息： 使用清晰且详细的提交信息来解释这次变更的目的和内容

feat: 表示新功能 (feat: 增加支付模块)常用

fix: 表示 bug 修复 (fix: 修复日期输入显示错误)常用

refactor: 表示代码重构（不新增功能也不修复bug） (refactor: 重构登录逻辑)常用

docs: 表示文档更新 (docs: 更新README内容)

style: 表示代码格式（不影响代码运行）更改 (style: 格式化代码)

test: 新增或修改测试 (test: 增加单元测试)

chore: 不修改src或测试文件的更改 (chore: 更新依赖包)

补充：rebase合并提交

git rebase -i [开始点] [结束点] 交互式界面rebase
git rebase -i HEAD~3 从HEAD指针开始的三个提交
git rebase -i [HASH]^ 从[HASH]开始到HEAD的所有提交

其中-i的意思是--interactive，即弹出交互式的界面让用户编辑完成合并操作，[startpoint] [endpoint]则指定了一个编辑区间，如果不指定[endpoint]，则该区间的终点默认是当前分支HEAD所指向的commit(注：该区间指定的是一个前开后闭的区间)。

查看提交log

git log --oneline

合并提交

git rebase -i 9f2bc16^

进入到编辑界面，修改需要改动的提交，以下是对提交执行的指令

pick：保留该commit（缩写:p）

reword：保留该commit，但我需要修改该commit的注释（缩写:r）

edit：保留该commit, 但我要停下来修改该提交(不仅仅修改注释)（缩写:e）

squash：将该commit和前一个commit合并（缩写:s）

fixup：将该commit和前一个commit合并，但我不要保留该提交的注释信息（缩写:f）

exec：执行shell命令（缩写:x）

drop：我要丢弃该commit（缩写:d）

进入提交注释信息修改界面，在提示处写上注释信息

保存后再查看日志信息

七、踩坑总结

前面都在讲rebase master/ rebase release。那肯定有疑惑为什么不能merge master。本人当初就是没有深刻理解merge和rebase，用了merge master，在上线阶段时司机执行 rebase master导致了冲突，影响了上线的流程导致返工。现在来讲讲为什么不能用，其实只要理解得透彻也是可以用的，并且merge如果有冲突永远只需要解决一次，但是rebase可能要解很多次。

假设我们当前存在这样一个线上master分支，和开发feat分支。feat是master在最后紫色提交处切出去的。

可以看到，此时我们的feat分支领先master两个提交，落后master一个提交，当我们执行了merge master后，分支图如下图所示

master领先的一些提交会和我们当前feat分支提交生成一个新的提交，如果有冲突这里只需要解决一次冲突。此时我们的feat分支代码上是没有落后master的。但是可以看出，我们的feat分支提交还是比master少了个绿色的。那在此时如果执行了rebase master那是个什么情况呢，如下图所示

可以看到rebase会重新变基，也就是从最后一个分叉处，将feat分支的提交一个一个接到后面，此时如果我们先前的merge那次代码出现冲突，那此时的rebase必定出现冲突。最坏的情况就是每一个提交都会出现冲突，需要不断的解。但是我们的feat分支看起来就会非常的线性。那此时如果想要拯救上次merge master的结果，那就可以基于master切一个新分支，然后将我们的feat分支merge到该分支来解决。如下图所示。

第二个图中的红色节点就是我们的feat分支merge到feat-base上新的提交，此时feat-base会领先master一个提交，并且可以看出是线性的，没有分叉没有落后的提交，这时再执行rebase master就不会产生冲突，因为feat分支和master在merge那次已经解了冲突。

新人建议： 如果没有充分理解或者不大熟练的同学，就在master每次有更新时变基一次，如果工作区和暂存区有代码就先git stash，然后rebase最新的master后再git stash pop回来。