再话git merge和rebase

git merge​ 和 git rebase​ 都是用来将一个分支的更改合并到另一个分支的 Git 命令，但它们实现的方式和最终产生的提交历史记录非常不同。

想象一下你有两个分支：

• ​main​: 主分支，通常代表稳定的版本。
• ​feature​: 你自己开发新功能的分支，它是从 main​ 分支的某个旧点分叉出去的。

现在，main​ 分支上有了新的提交（比如别人合并了代码），而你的 feature​ 分支上也有了你自己的新提交。你想把 main​ 分支的最新更改同步到你的 feature​ 分支，或者最终把你的 feature​ 分支合并回 main​。这时你就可以选择 merge​ 或 rebase​。

1. git merge​ (合并)

• 工作方式：

  1. 找到两个分支（main​ 和 feature​）的共同祖先提交点。
  2. 将两个分支从共同祖先之后的所有差异整合起来。
  3. 在目标分支（比如你在 feature​ 分支上，想合并 main​ 的更新，目标就是 feature​）上创建一个新的“合并提交” (Merge Commit)。
  4. 这个合并提交很特殊，它有两个父提交：一个是目标分支合并前的最新提交，另一个是源分支（你要合并进来的那个分支）的最新提交。
  5. 它把两个分支的历史汇合到这一点。

• 结果历史记录：

  • 保留精确历史： 它忠实地记录了分支开发和合并的实际过程，你可以清楚地看到分支在何时分叉，又在何时合并回来。
  • 非线性（图谱复杂）： 提交历史图看起来会有很多分叉和汇合点，像一张网。如果合并频繁，历史记录可能显得“杂乱”。
  • 简单直观： 合并的概念相对容易理解。

• 冲突处理： 如果在合并过程中出现冲突（比如你和 main​ 分支都修改了同一个文件的同一行），你只需要解决一次冲突，然后完成这个合并提交。

• 命令示例 (将 main 合并到 feature 分支)：

  git checkout feature  # 切换到你的 feature 分支
  git merge main      # 将 main 分支的更改合并进来
  # (解决冲突，然后 git add . , git commit)
  

2. git rebase​ (变基)

• 工作方式：

  1. 找到两个分支（main​ 和 feature​）的共同祖先。
  2. 先把你的 feature​ 分支上独有的提交（从共同祖先之后开始）暂时保存起来，就像把它们“拎起来”放在一边。
  3. 将你的 feature​ 分支的“基础”移动到目标分支（比如 main​）的最新提交点上。
  4. 然后，把之前“拎起来”的那些 feature​ 分支的提交，一个接一个地重新应用（像打补丁一样）到新的“基础”上。
  5. 关键： 这些重新应用的提交不是原来的提交了，它们是新的提交，拥有新的哈希值 (SHA-1)，尽管它们包含相同的代码更改。原来的提交会被抛弃（除非有其他分支指向它们）。

• 结果历史记录：

  • 线性（整洁）： 提交历史看起来像一条直线，仿佛你的 feature​ 分支上的所有开发都是在 main​ 分支最新进展之后才开始的。
  • 重写历史： 因为它创建了新的提交并抛弃了旧的，所以它实际上是在修改历史记录。
  • 丢失上下文： 看不出你的功能分支实际上是在哪个时间点、基于哪个旧版本开发的。

• 冲突处理： 如果在重新应用每个提交的过程中遇到冲突，你可能需要多次解决冲突，每次解决完一个提交的冲突后，使用 git rebase --continue​ 继续应用下一个提交。

• 命令示例 (将 feature 分支变基到 main 分支上)：

  git checkout feature  # 切换到你的 feature 分支
  git rebase main      # 将 feature 分支的基础变更为 main 的最新提交
  # (循环解决冲突，每次解决后 git add . , git rebase --continue)