变基与合并对比

使用 Git 时，您经常会发现自己的分支与另一个分支出现分叉，例如您的 feature 分支与 main 分支之间。

如何将这些更改合并到一起？Git 提供了两种主要策略：合并和变基。两者都可以实现集成，但方式存在根本差异，因此会产生不同的项目历史。

合并是 Git 默认的更改集成方式。将一个分支合并到另一个分支时，Git 会获取源分支的内容，并将其与目标分支组合起来。

合并的关键特征是会创建一个新的合并提交。此提交有两个父提交，明确显示出两个分叉的历史被合并到了一起，同时保留两个分支的完整历史。

让我们来看一个简单的合并示例。我们将创建一个 feature 分支，添加一次提交，然后将其合并回 main。

合并操作简单，并且对共享分支来说很安全，但可能会导致历史记录显得“杂乱”。

• 优点：
• 保留提交的完整历史。
• 不会破坏现有提交，也不会重写它们。
• 简单易用、易于理解。
• 缺点：
• 可能产生包含大量合并提交的“嘈杂”历史。
• 多个分支合并进来时，图表可能显得很复杂。

变基是合并之外的另一种选择，它通过将一系列提交移动或组合到新的基提交上来集成更改。它不会创建合并提交，而是重写项目历史。

本质上，功能分支中的提交会被“重新应用”到目标分支的最新提交之上，使其看起来仿佛您是从那里开始工作的。这样可以创建一条线性历史，并避免额外的合并提交。

现在，让我们使用变基尝试相同的场景。我们将把 feature 分支变基到 main 上。

请注意，feature 分支的提交会被重新应用到 main 的最新提交之上，然后通过快进合并使 main 指向该提交。

变基可以创建整洁的历史，但对于共享分支，有一个重要的注意事项。

• 优点：
• 创建整洁的线性项目历史。
• 更易于浏览和理解提交历史。
• 集成前可以整理提交（压缩、重新排序）。
• 缺点：
• 会重写提交历史。
• 如果用于已推送到共享（公共）远程仓库的提交，可能会带来风险。

下面快速总结两者的核心区别：

• 合并：
• 创建新的合并提交。
• 保留完整且准确的历史。
• 不会破坏原有内容。
• 图表可能较为复杂。
• 变基：
• 重写历史，不创建合并提交。
• 生成线性历史。
• 具有破坏性（会改变提交标识）。
• 图表非常整洁。

那么，什么时候应该使用哪一种方式？

• 在以下情况下使用合并：
• 处理公共或共享分支时（例如 main、develop）。
• 需要保留项目的完整历史时。
• 希望明确显示分叉的历史何时被合并时。
• 在以下情况下使用变基：
• 推送前处理自己的私有功能分支时。
• 希望获得整洁的线性历史时。
• 集成前希望整理功能分支中的提交（例如压缩、重新排序）时。

黄金法则：绝不要对已经推送到共享远程仓库的提交进行变基！对共享历史进行变基可能会给协作者带来严重困扰。

请思考 Git 的两种主要集成策略各自的特点。

在本课中，我们探讨了 Git 集成更改的两种基本方式：合并和变基。

• 合并通过新的合并提交组合历史，并保留所有原始提交。
• 变基通过移动提交来重写历史，创建线性的开发流程。

请根据团队的工作流谨慎选择，并记住黄金法则：绝不要对公共历史进行变基！理解这一点对于维护整洁且便于协作的 Git 工作流至关重要。