git rebase 操作记录
场景一：Fast-Forward 合并
dev 分支合并到main 分支，不想产生一个新的合并节点，而是基于main分支生成最新commit，操作如下：
git checkout main # 切换到 main 分支
git pull origin main # 更新 main 到最新
git checkout dev # 切换到 dev 分支
git rebase main # 将 dev 的提交基于 main 的最新提交（已整合 main 的最新更改）git log --oneline # 查看 dev 分支的提交历史，确保 rebase 成功# 由于你已通过 rebase 或 merge 修改了 dev 分支的提交历史，需 强制推送（覆盖远程 dev 的历史）
git push origin dev --force
# 或简写为：
git push -f origin dev
什么是 Fast-Forward 合并？
Fast-Forward（快进合并） 是 Git 在合并分支时的一种优化方式，当 当前分支的提交历史是目标分支的直接后裔 时，Git 会直接移动目标分支的指针到当前分支的最新提交，而无需创建新的合并提交。
Fast-Forward 合并的条件
Fast-Forward 合并成立的 必要条件 是：
- 当前分支（如
feature）是目标分支（如main）的直接延伸。 - 当前分支没有与目标分支无关的独立提交。
示例 1：Fast-Forward 合并的典型场景
步骤 1：创建并切换到新分支
git checkout main # 当前在 main 分支
git checkout -b feature # 创建并切换到 feature 分支
步骤 2：在新分支提交更改
# 在 feature 分支进行开发并提交
git commit -m "添加新功能"
步骤 3：合并到 main 分支
git checkout main
git merge feature # 自动触发 Fast-Forward
合并结果：
main分支的指针直接移动到feature的最新提交。- 无新提交生成，提交历史呈线性。
示例 2：非 Fast-Forward 合并（存在独立提交）
步骤 1：在 main 和 feature 分支均有提交
# 在 main 分支提交
git checkout main
git commit -m "修复 main 分支的 bug"# 在 feature 分支提交
git checkout feature
git commit -m "完善新功能"
步骤 2：合并 feature 到 main
git checkout main
git merge feature # 此时无法 Fast-Forward
合并结果：
- Git 会创建一个新的 合并提交，保留分支的历史分支结构。
Fast-Forward 合并的优缺点
| 优点 | 缺点 |
|---|---|
| 提交历史线性化，无冗余合并提交 | 丢失分支的分支结构，无法追溯分支来源 |
| 简化历史查看 | 若分支有独立提交，需强制使用 --no-ff |
如何强制避免 Fast-Forward？
使用 --no-ff 选项，即使满足条件也强制创建合并提交：
git merge --no-ff feature
Fast-Forward 合并的可视化对比
Fast-Forward 合并：
A → B → C (main 和 feature 分支指针)↑feature 分支创建于 main 的 B 提交后提交 C 后合并，main 直接指向 C
非 Fast-Forward 合并：
main 分支：A → B → D (独立提交)
feature 分支：A → B → C (独立提交)
合并后：A → B → D → M (合并提交 M)↖ ↗C (feature)
总结
- 适用场景：当分支提交历史完全线性时，Fast-Forward 合并可简化历史。
- 注意事项：若需保留分支结构（如追溯功能开发路径），建议使用
--no-ff。 - 命令速记：
git merge --ff-only <branch>：仅 Fast-Forward 合并，失败则报错。git merge --no-ff <branch>：强制非 Fast-Forward 合并。