首页
关于
Search
1
git lg彩色显示日志
28 阅读
2
在 Ubuntu 22.04 LTS 中安装 Docker
19 阅读
3
CentOs/Ubuntu搭建上网x-ui
18 阅读
4
git使用多个源和多个分支
15 阅读
5
清理Windows臃肿程序
15 阅读
默认分类
网站搭建
Windows
Linux
Docker
OpenWrt
Hackintosh
Git
Python
Web开发
JavaScript
FFmpeg
Demo
工具
刷机
油猴脚本
Excel
Chrome Extension
登录
Search
标签搜索
Pandas
读取
时区
Chrome
centos8
求和
Nginx
Typecho
404
csv
国际站
询盘导出
油猴脚本
bbr
Ubuntu
远程桌面
日志
log
数据清洗
打印机
野生程序猿
累计撰写
153
篇文章
累计收到
0
条评论
首页
栏目
默认分类
网站搭建
Windows
Linux
Docker
OpenWrt
Hackintosh
Git
Python
Web开发
JavaScript
FFmpeg
Demo
工具
刷机
油猴脚本
Excel
Chrome Extension
页面
关于
搜索到
1
篇与
的结果
2025-12-18
深入理解 Git rebase:如何把“私有补丁”永久叠加在 dev 之上
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 中有一个非常适合这个需求的命令:rebaserebase 的本质语义是:将一组提交重新应用到另一个基点之上因此我们可以把整个问题理解为:dev 是不断前进的“主线”私有代码是一组需要长期叠加在主线之上的“补丁”三、推荐方案:使用 rebase 固定私有提交在最后适用前提当前分支可以 rebase(个人分支 / 约定可改历史)私有代码与 dev 的修改边界相对清晰1️⃣ 拉取 dev 最新代码git fetch origin2️⃣ 找到 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/devGit 会自动:先对齐最新的 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 (只包含私有功能)同步流程:git checkout feature-base git rebase origin/dev git checkout feature-private git rebase feature-base该模式适合:OEM / 客户定制长期多版本维护私有代码体量较大场景九、总结Git 完全可以做到:dev 持续更新私有代码永远位于最后提交历史清晰、冲突可控核心思想只有一句话:把私有代码当成“补丁”,用 rebase 永远叠加在 dev 之上如果你有需要,也可以把这套流程封装成脚本,实现 一键同步 dev,非常适合长期项目维护。
2025年12月18日
1 阅读
0 评论
0 点赞