我没有太多运气推动/拉动子树的变化。通常我会使用' git子树'命令创建子树并拉动更改。拉动时,我会得到蹩脚的冲突来解决(当真的没有冲突时),推动永远不会起作用。
所以今天我正在尝试一种不同的方法,使用子树合并而不是git子树命令。我按照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' branch是&fschwiet'的主席。科。我希望将该子程序建立在“旧”的基础之上。最初所以我可以测试拉动变化(拉动其余的' 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'科。但它并没有拉下任何东西。我确实验证了“老了”。和' 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
我错过了什么?
答案 0 :(得分:0)
我的错误在于
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 -s子树或git子树合并。这似乎做了一个更智能的合并算法。特别是,它删除了已删除的文件(与git子树合并不同)。