✍️记录自己的git分支管理实践

前言

👋 你好啊，我是你的人类朋友！

因为本人的开发经常涉及各个分支间的同步，这一套同步的流程从刚开始的小心翼翼，到现在相对熟悉了

所以我想记录下自己工作中常用的分支同步的步骤 😆

顺便研究康康有没有可以优化的地方 🍃

正文

先介绍下背景情况吧

首先主分支为 master

其次，因为开发分为多个阶段，比如 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# 1-2. 更新目标分支（保持不变）
2git checkout feature/phase_2
3git pull origin feature/phase_2
4
5# 3. 切换到开发分支
6git checkout feature/phase_2_devjjq
7
8# 4. ✨ 关键优化：使用 rebase 而不是 merge。这个步骤做的事情其实就是将 feature/phase_2_devjjq 分支的提交放到 feature/phase_2 分支的最新提交之后。
9git rebase feature/phase_2
10
11# 5. 解决可能的冲突（在 rebase 过程中）
12# 如果有冲突：
13git add .
14git rebase --continue
15
16# 6-7. 快速前进合并
17git checkout feature/phase_2
18git merge feature/phase_2_devjjq  # 这会是一个 fast-forward 合并
19
20# 8. 推送
21git push origin feature/phase_2
22

之前有写过关于 git 变基的文章，不太清楚这个概念的小伙伴可以去康康

关于git 的快速合并，我之前也有写过文章，不太清楚的小伙伴可以去康康！

详细解读

我原来的流程会产生多余的合并提交，让提交历史变得复杂。

我的优化核心： 在第 4 步用 rebase 代替 merge

优化后的效果是什么呢？

将我的提交“移植”到 phase_2 最新代码之后，保持提交线整洁
后续合并时能使用快速前进，不产生额外合并提交
最终提交历史是清晰的一条直线，便于追踪

😎 小总结： 我用 rebase 让我的改动“接上”最新代码，merge 时直接快速前进，保持提交历史干净利落。

最后

✍️ 上面就是我想分享的分支管理实践了以及优化后的效果了

抛砖引玉，希望能对大家有所帮助！

✍️记录自己的git分支管理实践

前言

正文

优化流程

详细解读

最后

相关链接