前言
你好啊，我是你的人类朋友！
由于本人的开发常常涉及各个分支间的同步，这一套同步的流程从刚开始的小心翼翼，到目前相对熟悉了
所以我想记录下自己工作中常用的分支同步的步骤
顺便研究康康有没有可以优化的地方
正文
先介绍下背景情况吧
第一主分支为 master
#Git #前端 #后端 #每天一个知识点其次，由于开发分为多个阶段，列如 phase_1 、phase_2 、phase_3 等
那就在 master 之后再创建 feature/phase_1 、feature/phase_2 这样的分支，作为每一个 phase 的主分支
每一个人的开发分支可以这样安排：我叫江建清，所以我的 phase2阶段 的开发分支的名称为 feature/phase_2_devjjq
重点来了，我目前要将我的 feature/phase_2_devjjq 分支的改动同步到 feature/phase_2 分支中
如何操作呢？
重点！重点！重点！
先上 git 命令，后面有文字版
- git checkout feature/phase_2
- git pull origin feature/phase_2
- git checkout feature/phase_2_devjjq
- 【✨ 将冲突放到 feature/phase_2_devjjq 分支解决，完全不影响 feature/phase_2 】 git merge feature/phase_2
- 解决好可能存在的冲突【注意，如果此处存在冲突，要进行解决，并且要做好测试。确保无误之后再进行后续的同步。⚠️❗ 核心的思路是：绝不可以将不能确定解决之后是否存在异常的内容推送到当前阶段的主分支，这一点在低代码领域尤其突出，需要更加谨慎】，然后将代码提交到 feature/phase_2_devjjq 分支中
- git checkout feature/phase_2
- git merge feature/phase_2_devjjq
- git push origin feature/phase_2
上面就是我目前的大致做法了。
用文字总结就是：
- 先切换到 feature/phase_2 分支
- 拉取 feature/phase_2 的最新代码（由于各个同事都会开发，也都会向这个分支提交代码）
- 切换到 feature/phase_2_devjjq 分支
- 合并 feature/phase_2 分支到 feature/phase_2_devjjq 分支
- 解决可能存在的冲突
- 切换到 feature/phase_2 分支
- 合并 feature/phase_2_devjjq 分支到 feature/phase_2 分支
- 推送 feature/phase_2 分支到远程仓库
好了，那我的流程有哪些可以优化的地方？
优化流程
当前的流程总结下来是这样的：
步骤分解：
- git checkout feature/phase_2 ✅
- git pull origin feature/phase_2 ✅
- git checkout feature/phase_2_devjjq ✅
- git merge feature/phase_2 ⚠️ (产生合并提交)
- 解决冲突 ✅
- git checkout feature/phase_2 ✅
- git merge feature/phase_2_devjjq ⚠️ (再次产生合并提交)
- git push origin feature/phase_2 ✅
我们可以这样优化：
# 1-2. 更新目标分支（保持不变）
git checkout feature/phase_2 git pull origin feature/phase_2
# 3. 切换到开发分支
git checkout feature/phase_2_devjjq
# 4. ✨ 关键优化：使用 rebase 而不是 merge。这个步骤做的事情实则就是将 feature/phase_2_devjjq 分支的提交放到 feature/phase_2 分支的最新提交之后。
git rebase feature/phase_2
# 5. 解决可能的冲突（在 rebase 过程中）
# 如果有冲突：
git add . git rebase --continue
# 6-7. 快速前进合并
git checkout feature/phase_2 git merge feature/phase_2_devjjq # 这会是一个 fast-forward 合并
# 8. 推送
git push origin feature/phase_2
之前有写过关于 git 变基 的文章，不太清楚这个概念的小伙伴可以 去康康
关于 git 的快速合并 ，我之前也有写过文章，不太清楚的小伙伴可以 去康康！
详细解读
我原来的流程会产生多余的合并提交，让提交历史变得复杂。
我的优化核心： 在第 4 步用 rebase 取代 merge
优化后的效果是什么呢？
- 将我的提交“移植”到 phase_2 最新代码之后，保持提交线整洁
- 后续合并时能使用快速前进，不产生额外合并提交
- 最终提交历史是清晰的一条直线，便于追踪
小总结： 我用 rebase 让我的改动“接上”最新代码，merge 时直接快速前进，保持提交历史干净利落。
最后
✍️ 上面就是我想分享的分支管理实践了以及优化后的效果了
抛砖引玉，希望能对大家有所协助！
相关链接
- 说说 git 的变基
- git 中的 Fast-Forward 是什么？
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
暂无评论...