Git中的变基(Rebase)

Git 操作之变基（Rebase）

⭐⭐⭐

目录

🔔 介绍

在Git中，下载后运行变基通常是指使用

git pull

命令结合

--rebase

选项，从远程仓库获取最新的更新并将其应用到当前分支的操作。与默认的

git pull

不同，

--rebase

选项会将远程分支的更改应用到你的提交之下，以保持提交历史的线性。

变基操作会将当前分支的提交“移植”到另一个基点上，这个基点通常是远程分支的最新提交。这种操作会重写提交历史，使其看起来像是从新的基点上直接进行的开发。

🔔 格式

git pull --rebase origin branch-name

🔎运行变基的步骤：

1. 获取（Fetch）: 首先，git pull --rebase 会从远程仓库获取最新的更新。
2. 变基（Rebase）: 然后，它会将本地分支的提交移植到获取的更新之上。

🔔 示例

假设你在一个名为

feature

的分支上工作，而远程仓库的主分支是

main

。

main

分支有新的更新，而你的

feature

分支有一些本地提交。

1. 🔎变基前仓库的状态A---B---'C' main \ D---E feature
2. 🔎运行 git pull --rebasegit pull --rebase origin main
3. 🔎Git会获取 main 分支的最新提交：A---B---C'---F---G' main \ D---E feature
4. 🔎Git会将 feature 分支的提交 D 和 E 移植到 main 分支的最新提交 G 之后：A---B---C---F---'G' main \ D---E feature
5. 🔎变基后 feature 分支的基点从 C 移植到 main 分支的最新提交 G

🔔 特性

• 历史记录更清晰: 变基后的提交历史是线性的，便于阅读和理解。
• 避免合并提交: 通过变基，可以避免生成不必要的合并提交，从而保持提交历史的简洁。
• 冲突处理更明确: 在变基过程中，每个提交的冲突会逐个处理，更容易定位和解决冲突。
• 重写历史: 变基会重写提交历史，因此在已经推送到共享仓库的分支上运行变基可能会导致问题。其他开发者的工作可能会受到影响。

🔔 变基与合并的区别

📄合并变基操作方式合并会创建一个新的合并提交，并保留原始的提交历史。变基会将当前分支的提交移植到新的基点上，保持提交历史主要用途

• 合并两个或多个开发历史

• 维持项目中的并行开发历史。

• 在推送到远程仓库之前更新本地分支。

• 保持一个线性的提交历史。

优点

• 保留了代码开发的实际历史和并行工作的上下文。

• 操作安全，不改写历史，不会对其他协作者的工作造成影响。

• 提供干净、直线的历史记录，没有分支合并的节点。

• 可以简化代码的理解和审查过程。

缺点

• 历史记录可能会变得复杂，特别是在频繁的分支和合并的情况下。

• 合并提交本身有时可以显得多余，尤其是在小型项目或者少数开发者参与时。

• 变基过程中可能发生的冲突需要逐个解决，有时可能比较复杂。

• 改写历史可能会对基于原有提交历史工作的其他开发者造成困扰。

🔔 使用场景

📄 保持分支同步： 当你在一个长期存在的分支上工作，并且主分支（例如 main 或 master）有了新的更新时，你可以使用变基来保持你的分支与主分支同步。

📄 清理提交历史： 在进行代码审查或将本地工作推送到远程仓库之前，清理提交历史可以使提交更具可读性和逻辑性。
在分支上进行变基，将多个小的提交合并成一个逻辑提交，或对提交进行重新排序和编辑：

git rebase -i HEAD~n

其中，

n

是你要变基的提交数。