跟踪通过`git subtree`合并的外部git repos答案

【问题标题】：Keeping track of external git repos merged through `git subtree`跟踪通过`git subtree`合并的外部git repos
【发布时间】：2013-03-01 20:20:38
【问题描述】：

我正在尝试建立一个良好的模式来管理跨多个项目的共享代码和外部依赖项。由于其他地方有详细记录的原因，使用子模块有很多陷阱，我倾向于远离它。从 git 1.8 开始，子树命令是内置的，似乎涵盖了我关心的很多内容，但仍然有一些核心场景似乎缺失。我希望有人在填补空白的官方子树功能之上编写了一些脚本。

我想要的似乎缺少的是：

这些东西是内置在命令中的吗？我只是在它们的使用方式上遗漏了一些东西？我还要求这需要在 Windows 上运行，以防影响任何事情。

谢谢，

【问题讨论】：

我的编译自官方源代码git 1.8.1.5 版没有git subtree 命令。也许它是一个附加组件或来自contrib 位的东西，或者也许你有一个候选版本 (1.8.2-rc)...
git --version 显示 git version 1.8.1.msysgit.1。我昨天使用官方 Windows 二进制文件从 1.7 升级。我最初是从 github 存储库中查看它的，但它目前有这个文档：github.com/apenwarr/git-subtree/blob/master/…，评论它被集成到 git 中。
不，它从未集成到 git 中——它是 git contrib 文件夹的一部分——这并不意味着它是自动安装的。见这里：github.com/git/git/tree/master/contrib/subtree
啊，我没有意识到存在区别。感谢您的澄清。
嗨，乔 - 一年多以前你问过这个问题。我试图弄清楚完全相同的事情。你最终选择了什么？我的主要问题是您的第一个项目符号-跟踪子树的来源。谢谢！

【解决方案1】：

不，这样的命令不存在。像这样的命令也很难实现，因为 git-subtree 不会将子树的来源存储为元数据。如果你想要这样的功能，我强烈推荐子模块。不过，它们还需要您编写一些脚本来实现您想要的。

【讨论】：

使用分离的头部似乎容易出错，并且通常很容易进入我们可能会丢失工作的状态，我认为我应该避免使用子模块。我没有尝试在任何大型项目中使用它们，但同事们有并且有强烈的负面意见。在 Google 上搜索此场景的一般选项时，我发现没有多少页面推荐子模块作为解决此问题的好方法。如果它真的更好并且可以通过脚本变得安全，那么我很乐意尝试。
另外，我已经看到像 endot.org/2012/02/12/git-subtree-tracking-made-easy 这样的事情，它开始朝着我正在寻找的使用子树的工作流程构建。我希望有人能更进一步，并使用已签入 Git/contrib 的版本，而不是作为单独的 fork。
分离头状态确实有点危险。但是无论如何，在处理代码时和提交之前，您应该检查您所在的分支。