使用git checkout -b和git rebase操作时提交历史是否存在差异

结论先行 #

两种操作最终都能拿到feature/1的全部代码，但对提交历史的影响存在明显差异。 #

方式1的提交历史表现 #

操作步骤：

# 当前HEAD指向feature/1
git checkout -b feature/2

• 本质是直接在feature/1的最新提交节点上切出新分支feature/2，所有历史完全继承feature/1的原有记录
• feature/1的所有提交的哈希值、提交时间、提交人、父节点信息完全不会发生变化
• 提交历史是完全线性的：master原有提交 → feature/1全量提交 → feature/2后续新提交，不会生成任何额外的冗余提交

方式2的提交历史表现 #

操作步骤：

# 当前HEAD指向master
git checkout -b feature/2
git rebase feature/1

• 首先从master的最新节点切出空的feature/2分支，再将feature/1的所有提交逐个重放到feature/2分支上
• 即使此时feature/2还没有任何新提交，重放后的feature/1相关提交也会生成全新的哈希值，和原feature/1分支的提交已经不属于同一个提交节点
• 如果后续feature/1有迭代更新需要再次同步到feature/2，重复执行变基操作会重复重放所有差异提交，额外增加冲突处理成本

适用场景区分 #

• 方式1适合feature/2完全基于feature/1开发，后续不需要单独和master同步变更的场景
• 方式2适合feature/2本身有独立于feature/1的开发需求，同时需要保持提交历史线性整洁的场景

内容的提问来源于stack exchange，提问作者HackerMF