rebase 变基引发提交哈希重写与指针机制分析

rebase 变基引发提交哈希重写与指针机制分析

线上排查问题，git log 全是 Merge branch 提交，bisect 根本没法用。这就是乱用 merge 导致的历史污染。很多团队强制 rebase，但不知道底层哈希会变，导致推送失败甚至丢失提交。老项目里这种坑我见过太多，今天把底层机制讲透，别再用错误姿势操作分支。

变基本质是指针跳跃

rebase 不是移动提交，是复制提交。原 commit A 哈希是 hash1，rebase 后变成新 commit A' 哈希 hash2。因为父指针变了，内容哈希自然变。很多人 rebase 后 push 失败，就是因为本地哈希和远程不一致。Git 存储依赖 SHA-1 校验，父节点改变，当前节点哈希必然改变，这是数据结构决定的。

复制代码

git checkout feature
git rebase main

输出：Successfully rebased and updated refs/heads/feature。此时 feature 分支指针指向新哈希链，旧哈希链若无人引用会被 GC 回收。这意味着变基是不可逆的历史重写，公共分支千万别干，否则同事拉代码会冲突到怀疑人生。

Cherry-pick 精准移植场景

不要为了同步代码全量 rebase。某个修复补丁需要同步到 release 分支，用 cherry-pick。这比 merge 整个分支更干净，只拿需要的逻辑。适合 hotfix 场景，避免把未测试的开发代码带入生产分支。

复制代码

git checkout release/v1.0
git cherry-pick -x 8f3a2b1

输出： $release/v1.0 9c4d5e2$ fix: null pointer exception。-x 参数自动在原提交信息后加注来源，方便追溯是哪次提交变过来的。遇到冲突时，解决完文件记得 git add 然后 git cherry-pick --continue，别直接 commit 断了链，否则后续追溯不到原始作者。

分支模型落地策略

主分支 main 保护，禁止直接 push。开发分支 feature 基于 main 创建。提测前必须 rebase main 保持线性。这样 Code Review 时只看差异，不被合并提交干扰。线性历史让回滚和定位问题变得简单，减少认知负担。

复制代码

git pull --rebase origin main
git push origin feature --force-with-lease

输出：Enumerating objects... done。--force-with-lease 确保不会覆盖别人刚推的代码，比强制 push 安全得多。如果远程有你不知道的提交，命令会拒绝执行，防止误删同事代码。这是协作底线，别为了省事直接用 -f。

老兵避坑清单

公共分支严禁 rebase，除非你清楚所有协作者进度。
变基前务必 fetch，确认远程最新状态。
冲突解决后不要直接 commit，用 git rebase --continue。
操作失误用 reflog 找回旧哈希，git reflog show HEAD。
合并大特性分支用 merge --no-ff 保留节点，方便回滚。
本地提交没推之前随便 rebase 整理，推了之后就当化石别动。
复杂冲突建议中止 rebase，手动 merge 解决后再重新变基。

提交历史是团队的共同资产，乱改哈希等于篡改账本。理解指针指向机制，才能知道什么时候该变基，什么时候该合并。工具是死的，人是活的，根据团队规模选择合适模型才是关键。

你们团队是坚持线性历史还是保留合并节点？