[[r_subtree_merge]]
===== 子树合并

子树合并的思想是你有两个项目，并且其中一个映射到另一个项目的一个子目录，或者反过来也行。
当你执行一个子树合并时，Git 通常可以自动计算出其中一个是另外一个的子树从而实现正确的合并。

我们来看一个例子如何将一个项目加入到一个已存在的项目中，然后将第二个项目的代码合并到第一个项目的子目录中。

首先，我们将 Rack 应用添加到你的项目里。
我们把 Rack 项目作为一个远程的引用添加到我们的项目里，然后检出到它自己的分支。

[source,console]
----
$ git remote add rack_remote https://github.com/rack/rack
$ git fetch rack_remote
warning: no common commits
remote: Counting objects: 3184, done.
remote: Compressing objects: 100% (1465/1465), done.
remote: Total 3184 (delta 1952), reused 2770 (delta 1675)
Receiving objects: 100% (3184/3184), 677.42 KiB | 4 KiB/s, done.
Resolving deltas: 100% (1952/1952), done.
From https://github.com/rack/rack
 * [new branch]      build      -> rack_remote/build
 * [new branch]      master     -> rack_remote/master
 * [new branch]      rack-0.4   -> rack_remote/rack-0.4
 * [new branch]      rack-0.9   -> rack_remote/rack-0.9
$ git checkout -b rack_branch rack_remote/master
Branch rack_branch set up to track remote branch refs/remotes/rack_remote/master.
Switched to a new branch "rack_branch"
----

现在在我们的 `rack_branch` 分支里就有 Rack 项目的根目录，而我们的项目则在 `master` 分支里。
如果你从一个分支切换到另一个分支，你可以看到它们的项目根目录是不同的：

[source,console]
----
$ ls
AUTHORS         KNOWN-ISSUES   Rakefile      contrib         lib
COPYING         README         bin           example         test
$ git checkout master
Switched to branch "master"
$ ls
README
----

这个是一个比较奇怪的概念。
并不是仓库中的所有分支都是必须属于同一个项目的分支.
这并不常见，因为没啥用，但是却是在不同分支里包含两条完全不同提交历史的最简单的方法。

在这个例子中，我们希望将 Rack 项目拉到 `master` 项目中作为一个子目录。
我们可以在 Git 中执行 `git read-tree` 来实现。
你可以在 <<ch10-git-internals#ch10-git-internals>> 中查看更多 `read-tree` 的相关信息，现在你只需要知道它会读取一个分支的根目录树到当前的暂存区和工作目录里。
先切回你的 `master` 分支，将 `rack_back` 分支拉取到我们项目的 `master` 分支中的 `rack` 子目录。

[source,console]
----
$ git read-tree --prefix=rack/ -u rack_branch
----

当我们提交时，那个子目录中拥有所有 Rack 项目的文件 —— 就像我们直接从压缩包里复制出来的一样。
有趣的是你可以很容易地将一个分支的变更合并到另一个分支里。
所以，当 Rack 项目有更新时，我们可以切换到那个分支来拉取上游的变更。

[source,console]
----
$ git checkout rack_branch
$ git pull
----

接着，我们可以将这些变更合并回我们的 `master` 分支。
使用 `--squash` 选项和使用 `-Xsubtree` 选项（它采用递归合并策略），都可以用来可以拉取变更并且预填充提交信息。
（递归策略在这里是默认的，提到它是为了让读者有个清晰的概念。）

[source,console]
----
$ git checkout master
$ git merge --squash -s recursive -Xsubtree=rack rack_branch
Squash commit -- not updating HEAD
Automatic merge went well; stopped before committing as requested
----

Rack 项目中所有的改动都被合并了，等待被提交到本地。
你也可以用相反的方法——在 master 分支上的 `rack` 子目录中做改动然后将它们合并入你的 `rack_branch` 分支中，之后你可能将其提交给项目维护着或者将它们推送到上游。

这给我们提供了一种类似子模块工作流的工作方式，但是它并不需要用到子模块（有关子模块的内容我们会在 <<r_git_submodules>> 中介绍）。
我们可以在自己的仓库中保持一些和其他项目相关的分支，偶尔使用子树合并将它们合并到我们的项目中。
某些时候这种方式很有用，例如当所有的代码都提交到一个地方的时候。
然而，它同时也有缺点，它更加复杂且更容易让人犯错，例如重复合并改动或者不小心将分支提交到一个无关的仓库上去。

另外一个有点奇怪的地方是，当你想查看 `rack` 子目录和 `rack_branch` 分支的差异——来确定你是否需要合并它们——你不能使用普通的 `diff` 命令。
取而代之的是，你必须使用 `git diff-tree` 来和你的目标分支做比较：

[source,console]
----
$ git diff-tree -p rack_branch
----

或者，将你的 `rack` 子目和最近一次从服务器上抓取的 `master` 分支进行比较，你可以运行：

[source,console]
----
$ git diff-tree -p rack_remote/master
----
