git rebase main

[!info] 阅读导览
全文 4 节：rebase 之前的提交历史（1.1）→ rebase 之后的历史变化（1.2）→ 实际操作三步（1.3）→ 提示和注意事项（1.4）

flowchart LR
    A[feature 分支：D→E 基于 B] --> B[git rebase main]
    B --> C[feature 分支：D'→E' 接到 C 之后<br>内容相同 · 提交 ID 重写]

1. git rebase main

1.1. 场景 1：rebase 之前

假设你的提交历史如下：

  • 主分支（main）：A -> B -> C
  • 功能分支（feature）：从 B 分叉，包含提交 D -> E。

图中左侧显示：

A---B---C (main)
     \
      D---E (feature)

这里的 feature 分支是从 main 的提交 B 开始的。

1.2. 场景 2：rebase 之后

当你对 feature 执行 git rebase main 后：

  • feature 的提交（D 和 E）被"移动"到 main 最新提交 C 的后面。
  • 历史看起来更像是线性发展的，像 D 和 E 是直接基于 main 的延续。

图中右侧显示：

A---B---C---D'---E' (feature)

这里的 D' 和 E' 是新的提交（它们的内容和 D、E 相同，但提交 ID 已经改变）。

1.3. 实际操作

  1. 切换到你的功能分支：

    git checkout feature

  2. 执行 rebase 操作：

    git rebase main

  3. 如果有冲突，按照提示解决冲突后继续：

    git rebase --continue

1.4. 提示和注意事项

  1. 整理历史：rebase 可以让提交历史更清晰，尤其在需要共享代码时，线性的提交历史更容易阅读和理解。
  2. 慎用在已推送的分支上：如果分支已经被其他开发者使用（比如已推送到远程仓库），rebase 会改变提交历史，可能引发冲突。
  3. 替代选择：如果不想改变历史，可以使用 merge，虽然会产生额外的合并节点，但更安全。

[!success] 核心要点

  • rebase 前：feature 从 main 的提交 B 分叉，包含提交 D → E
  • rebase 后：D’、E’ 被移动到 main 最新提交 C 之后，内容与 D、E 相同，但提交 ID 已改变，历史呈线性
  • 操作三步：git checkout feature → git rebase main → 有冲突则解决后 git rebase --continue
  • 注意事项：已推送分支慎用 rebase（会重写提交历史、可能引发冲突）；不想改变历史可用 merge（多一个合并节点但更安全）