git变基

原理

Git 里的提交可以看作是文件系统的快照，每个提交都指向它的父提交。当你在一个分支上进行多次提交时，这些提交会形成一个提交链。
假设存在 main 分支和基于 main 分支创建的 feature 分支。在你于 feature 分支开展工作期间，main 分支也有了新的提交。这时候，feature 分支和 main 分支的提交历史就产生了分叉。
变基操作的原理就是把 feature 分支上的提交从原来的基础提交上移除，然后将这些提交依次应用到 main 分支的最新提交之后。这样一来，提交历史就变成了线性的，仿佛所有的工作都是按顺序依次完成的。

实例

初始状态

假设你有一个 main 分支，它有 3 个提交：A、B、C。然后你基于 main 分支创建了 feature 分支，并在 feature 分支上进行了 2 个提交：D、E。此时的提交历史如下：

main: A - B - C
             \
feature:       D - E

main 分支有新提交

在你开发 feature 分支的过程中，main 分支又有了新的提交 F。提交历史变为：

main: A - B - C - F
             \
feature:       D - E

执行变基操作

你决定将 feature 分支变基到 main 分支上。首先切换到 feature 分支：

git checkout feature

然后执行变基命令：

git rebase main

变基操作的具体步骤如下：

• 保存提交：Git 会把 feature 分支上的提交 D 和 E 保存为补丁文件。
• 更新基础：将 feature 分支的基础提交更新为 main 分支的最新提交 F。
• 应用补丁：依次将保存的补丁文件应用到 F 之后。如果在应用补丁的过程中出现冲突，你需要手动解决冲突，然后使用 git add <冲突文件> 和 git rebase --continue 命令继续变基。
  变基完成后，提交历史变为：

main: A - B - C - F
                    \
feature:             D' - E'

这里的 D' 和 E' 表示变基后重新应用的提交，它们的提交哈希值可能会发生变化。

合并变基后的分支

变基完成后，你可以切换回 main 分支，并将 feature 分支合并到 main 分支上：

git checkout main
git merge feature

由于变基后的 feature 分支是基于 main 分支的最新提交，所以这次合并是一个快进合并（Fast-forward merge），提交历史仍然保持线性：

main: A - B - C - F - D' - E'

与合并操作的对比

• 提交历史：合并操作会创建一个新的合并提交，导致提交历史出现分叉；而变基操作会将提交历史整理成线性的，使提交历史更加简洁。
• 操作复杂度：合并操作相对简单，只需要创建一个合并提交即可；而变基操作可能会出现冲突，需要手动解决冲突，操作相对复杂。
• 应用场景：如果希望保持提交历史的线性，方便后续的代码审查和版本管理，可以使用变基操作；如果希望保留分支的开发历史，并且不介意提交历史出现分叉，可以使用合并操作。

实战运用

• 第一步，查看本地分支local_dev的近两次提交记录：
  
• 第二步，创建新分支后，回到原分支，再次提交：
  
  可以看到哈希值为193d的提交，该提交在原分支local_dev下
• 第三步，创建分支后，在新分支提交修改：
  
  可以看到相比原分支多了两个新的哈希值6398、c38c
  此时原分支和新分支都有了新的提交，我们开始变基，目标是把新分支再加回到原分支
• 第四步，使用变基，使用如下两个指令

git checkout local_dev
git merge local_dev1

• 第四步，查看变基效果:
  在新分支看历史记录如下
  
  可见多了两个哈希68ab、491b，这两个哈希来自于local_dev1 的提交，但是哈希值变了
  在原分支看历史记录如下：
  
  可见相比于最初始的状态，多了三个哈希值，分别是68ab、491b、193d,变基的效果达到了