Git 实战：持续合并 dev 更新，并让私有代码始终位于最后提交

在实际开发中，我们经常会遇到这样一种场景：

dev 分支在持续更新（主线开发）
我们基于 dev 派生了一个 定制分支 / 魔改分支 / 私有功能分支
该分支中存在 dev 分支永远不会合入的私有代码
需求是：

持续同步 dev 的最新更新，但始终保证私有代码位于提交历史的最后，不被 dev 覆盖

这种需求在以下场景中非常常见：

OEM 定制版本
客户专用功能分支
内部增强版 / 魔改版
长期维护的补丁分支

本文将介绍一种 Git 原生、稳定、可长期使用 的解决方案。

一、问题本质分析

我们先抽象一下分支结构：

dev:      A -- B -- C -- D
                   \
feature:             E -- F   （私有代码）

我们的目标是：

dev 每增加新提交（D → E → F → G…）
feature 能持续同步 dev
同时满足：
- 私有提交 始终在最末尾
- 提交历史尽量保持线性、干净

二、核心思路：把私有代码当成“补丁”

Git 中有一个非常适合这个需求的命令：rebase

rebase 的本质语义是：

将一组提交重新应用到另一个基点之上

因此我们可以把整个问题理解为：

dev 是不断前进的“主线”
私有代码是一组需要长期叠加在主线之上的“补丁”

三、推荐方案：使用 rebase 固定私有提交在最后

适用前提

当前分支可以 rebase（个人分支 / 约定可改历史）
私有代码与 dev 的修改边界相对清晰

1️⃣ 拉取 dev 最新代码

git fetch origin

2️⃣ 找到 dev 与当前分支的分叉点

git merge-base feature origin/dev

该命令会输出一个 commit hash，记为：

<BASE_COMMIT>

它是 feature 与 dev 的最后一个公共祖先。

3️⃣ 核心命令：将私有提交重放到 dev 之上

git rebase --onto origin/dev <BASE_COMMIT> feature

这条命令做了什么？

等价于：

将 feature 分支中
从 <BASE_COMMIT> 之后的所有提交
重新应用到 origin/dev 的最新提交之上

4️⃣ rebase 后的分支结构

dev:      A -- B -- C -- D
                            \
feature:                      E' -- F'

📌 私有提交始终位于最后

四、以后 dev 再更新，怎么同步？

如果私有代码始终只存在于 feature 分支中，后续同步将非常简单：

git checkout feature
git fetch origin
git rebase origin/dev

Git 会自动：

先对齐最新的 dev
再把你的私有提交 重新应用到最后

五、冲突会发生在哪里？

这是该方案的一个重要优势：

冲突 只会发生在私有提交中
dev → dev 的提交之间不会产生冲突
冲突范围清晰、可控

非常适合 长期维护型分支。

六、注意事项（重要）

⚠️ 1. rebase 会改写提交历史

请确保：

当前分支是个人维护分支
或团队已明确约定该分支可以 rebase

如果已经推送过远程，需要使用：

git push --force-with-lease

⚠️ 2. 私有代码应尽量拆分成独立提交

建议实践：

一个私有功能一个 commit
不要把私有代码与 dev 修改混在同一个提交中

这样可以：

降低 rebase 冲突概率
提高长期可维护性

七、不能 rebase 的替代方案（补充）

在以下场景中，rebase 可能不适用：

多人同时在该分支协作
分支已被下游依赖，不能改历史

此时可以使用：

merge + 固定“补丁提交”策略

约定规则：

feature 分支最后一个提交永远是私有补丁

同步流程：

git checkout feature
git fetch origin
git merge origin/dev

如遇冲突，可优先保留当前分支：

git checkout --ours .
git commit

缺点是：

提交历史不够线性
merge commit 较多

但在受限条件下依然可用。

八、进阶工程实践：私有代码独立分支模型

在企业级项目中，常见如下结构：

origin/dev
    |
feature-base        （仅同步 dev，不写私有代码）
    |
feature-private     （只包含私有功能）