《使用 Git 进行版本控制》第三版

第 6 章 合并 合并

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

由于 Git 是一个分布式版本控制系统， ，它允许分散在不同地理位置的开发人员独立进行修改和记录，并允许两个或多个开发人员随时合并他们的修改，而这一切都离不开一个中央仓库。从技术上讲，这是一种合并两个或多个不同开发线路的操作，在 Git 中正式称为合并。

在本章中，我们将通过一些简单的合并示例来讲解如何合并两个或多个不同的开发线，并分享一些解决合并冲突的技巧。我们还将讨论 Git 中的合并策略，并一探合并操作执行时 Git 对象存储中会发生什么。

合并：技术视角

在 Git 中，合并是将两个或多个 分支的提交历史统一起来。虽然 Git 支持同时合并三个或更多分支，但合并通常只合并两个分支。

合并必须在 单个版本库中进行，也就是说，所有要合并的分支都必须在同一个版本库中。至于这些分支是如何出现在同一个版本库中的，这并不重要。(在第 11 章中你会看到，Git 提供了引用其他版本库和将远程分支引入当前版本库的机制）。

当一个分支中的修改与另一个分支中的修改不冲突时，Git 会计算合并结果，并创建一个新的提交，代表新的统一状态。但当分支间有冲突时，Git 不会解决争议。相反，Git 会在索引中把这些有争议的修改标记为 "未合并"，然后让你--开发者--来调节（重申一下我们在"Git 的特点 "一文中的解释：Git 等待你的指示，告诉你该做什么，什么时候做）。当 Git 无法自动合并分支时，也要由你在所有冲突解决后进行最终提交。

合并示例

git merge 操作对上下文敏感。 当前分支始终是目标分支，其他分支的更改会合并到当前分支。

在下面的示例中，我们将切换到我们的 main-branch作为当前分支，并将一个 modified-branch并入它：

    $ git checkout main-branch
    $ git merge modified-branch
    

提示

要记住 Git 中的合并操作，一个更简单的方法是从源分支和目标分支的角度来考虑--也就是说，你在另一个分支（源分支）中做了一些改动，你想把这个分支合并到当前分支（目标分支）中。

让我们来看一对合并的例子，一个没有冲突，一个有大量重叠。为了简化本章的示例，我们将按照第 3 章介绍的技术使用多分支。

准备合并

一般来说，如果每次合并都从一个干净的工作目录和索引开始，你的 Git 生活会 轻松得多。在正常的合并过程中，Git 会创建新版本的文件，并在合并完成后把它们放到你的工作目录中。此外，Git 还会使用索引来存储操作过程中的临时和中间版本文件。

如果你在工作目录中修改了文件，或者通过git add 或git rm 修改了索引，那么你的版本库就有一个脏的工作目录或索引。如果在脏状态下开始合并，Git 可能无法一次性合并所有分支和工作目录或索引中的修改。

提示

你不必从一个干净的目录开始。Git 仍会执行合并操作，例如，如果受合并操作影响的文件和工作目录中的脏文件不常受引入的变更影响。不过，从干净的目录开始更容易，也是我们更喜欢的策略。

合并两个分支

在最简单的情况下，让我们用单个文件建立一个 仓库，创建两个分支，然后再将这对分支合并到一起：

    $ mkdir merge-conflict

    # Initialize new repository
    $ git init -b main Initialized empty Git repository ...