QIN BLOG
0%

谈谈 git merge 和 git rebase

发表于 分类于

git rebase 和 git merge 都是 Git 中用于整合不同分支的命令，但它们的工作方式和产生的历史记录截然不同。理解它们的区别是有效管理 Git 项目的关键。

git merge (合并)

git merge 的作用是将一个或多个分支的更改合并到当前分支。它会创建一个新的合并提交 (merge commit) ，这个提交有两个或更多的父提交，将两个分支的历史连接起来。

  • 非破坏性： 不会改变任何现有提交的历史，而是通过创建新的合并提交来记录分支的合并点。

  • 保留历史： 完整地保留了所有分支的合并历史，包括每个分支的独立演变过程。

  • 产生合并提交： 每次合并都会产生一个额外的合并提交，这可能会使提交历史看起来像“网状”或“分叉状”。

  • 示例： 假设你在 main 分支上，并有一个 feature 分支。

    1
    2
    3
    A -- B -- C (main)
         \
          D -- E (feature)

    执行 git checkout main 后 git merge feature：

    1
    2
    3
    A -- B -- C -- F (main, merge commit)
         \    /
          D -- E (feature)

    这里的 F 就是合并提交。

git rebase (变基)

git rebase 的作用是将一个分支的更改“重放”到另一个分支的顶端。它会改变提交历史，使得你的分支看起来像是从目标分支的最新提交之后直接创建的。本质上，rebase 会重写历史。

  • 重写历史： 会修改被变基的提交的 SHA-1 值（因为它们的应用的基础提交变了），这在公共分支上操作非常危险。

  • 线性历史： 产生一个干净、线性的提交历史，没有多余的合并提交，看起来就像是按顺序进行的开发。

  • “移动”分支： 实际上是取消你当前分支上的所有提交，将它们应用到目标分支的最新提交之上，然后再重新提交这些更改。

  • 示例： 假设你在 feature 分支上，想要将 main 分支的最新更改变基到 feature 上。

    1
    2
    3
    A -- B -- C (main)
         \
          D -- E (feature)

    执行 git checkout feature 后 git rebase main：

    1
    2
    3
    4
    A -- B -- C -- D' -- E' (feature)
                ^
                |
             (main)

    这里的 D' 和 E' 是 D 和 E 提交的副本，但它们是在 C 提交之后创建的，因此 SHA-1 值会改变。原先的 D 和 E 仍然存在于 Git 对象的存储中，但不再被任何分支引用，最终会被垃圾回收。

什么时候使用 git rebase？

选择 rebase 还是 merge 取决于对项目历史记录的偏好以及工作流程。

通常会在以下情况考虑使用 git rebase：

  1. 保持提交历史的干净和线性：

    • 当你希望项目的提交历史是一条清晰的直线，没有分支和合并提交的痕迹时，rebase 是首选。这对于小型团队或个人项目尤其有用，因为它让 git log 看起来非常整洁。
    • 常见场景： 在你将自己的特性分支合并回主分支（例如 main 或 develop）之前，先将特性分支 rebase 到主分支的最新状态。这可以确保你的特性分支包含了主分支的所有最新更改，并减少合并时的冲突。

  2. 避免不必要的合并提交：

    • 如果你进行频繁的、小范围的合并（例如，每天都将 main 分支的最新更改拉取到你的特性分支），使用 merge 会产生大量的合并提交。rebase 可以避免这些额外的提交，使历史更简洁。

  3. 在将特性分支推送到远程仓库之前：

    • 在你将一个只在本地存在的特性分支准备好推送到远程仓库时，rebase 可以让你在推送前整合 main 分支的最新更改，确保你的特性分支基于最新的代码。

  4. 在私有分支上工作时：

    • 如果你的分支尚未推送到远程仓库，也没有其他人在其上工作，那么 rebase 是一个安全的选择。
    • 重要警告： 永远不要对已经推送到公共仓库的分支进行 rebase 操作！ 因为 rebase 会重写历史，如果其他人已经基于你旧的提交历史进行了开发，rebase 会导致他们的历史与你的冲突，造成严重的麻烦和数据丢失风险。这被称为“变基已发布的提交”。

总结选择策略

  • 如果注重历史的清晰和线性，并且在私有分支上工作，或者准备将本地分支推送到远程之前清理历史，使用 git rebase。
  • 如果想保留所有分支的完整演变历史（包括合并事件），并且更注重历史的真实性（即便它可能不那么“线性”），或者在公共分支上进行操作，请使用 git merge。

大多数团队会根据具体的工作流程和项目需求，在这两者之间进行权衡和选择。一个常见的模式是：在个人特性分支上，经常 rebase 到 main 分支以保持更新和清理历史；而当特性分支成熟并准备合并回 main 分支时，使用 git merge 来记录这次特性合并。