我在从子树推送/拉取更改时运气不佳。通常我使用"git-subtree"命令来创建子树并提取更改。当拉的时候，我会有一些蹩脚的冲突需要解决（当真的没有冲突的时候），而推永远不会起作用。
因此，今天我尝试了一种不同的方法，使用子树合并而不是git-subtree命令。我在https://help.github.com/articles/about-git-subtree-merges/.
首先，我创建了远程到存储库的文件，我想用它作为子树：
git remote add -f cumulonimbus-machine http://github.com/fschwiet/cumulonimbus-machine
git merge -s ours --no-commit cumulonimbus-machine/old
git merge -s ours --no-commit cumulonimbus-machine/fschwiet
"old"分支是"fschwiet"分支的父级。最初我想将子RE建立在"旧"的基础上，这样我就可以测试拉取更改（拉取"fschwiet"的其余部分）。无论如何，我创建子树：
git read-tree --prefix=host/ -u cumulonimbus-machine/old
这很好用。所有文件都在hosts文件夹中，我可以看到它的旧分支。然后我尝试获得一些更新：
git pull -s subtree cumulonimbus-machine fschwiet
我得到了一些令人失望的结果：
From http://github.com/fschwiet/cumulonimbus-machine
* branch fschwiet -> FETCH_HEAD
Already up-to-date
我原以为最后一次拉取会更新主机目录，使其具有"fschwiet"分支的最新版本。但它并没有摧毁任何东西。我确实验证了"old"one_answers"fschwiet"实际上不是同一个提交。我尝试了其他一些方法，得到了相同的结果：
git subtree merge --prefix=host cumulonimbus-machine/fschwiet
git merge -X subtree=host cumulonimbus-machine/fschwiet
git subtree pull --prefix=host cumulonimbus-machine 90686ba2d0c31afdc516611064
git subtree pull --prefix=host cumulonimbus-machine master
我错过了什么？
我的错误是运行
git merge -s ours --no-commit cumulonimbus-machine/fschwiet
之前
git read-tree --prefix=host/ -u cumulonimbus-machine/old
这创建了一个合并提交，拉入"旧"分支的内容，但告诉存储库它与"fschwiet"分支同步。
尽管如此，我还是学到了一些有价值的东西。如果我使用，我遇到的一些合并问题似乎可以解决
git merge -X subtree=host cumulonimbus-machine/fschwiet
而不是git merge的子树或git子树merge。这似乎是一种更智能的合并算法。特别是，它删除了已删除的文件（与git-subtreemerge不同）。