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 --rebase

   git 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 是你要变基的提交数。