在 Git 中为多个项目组织外部库

Question

问题

我希望我的公司将所有包含的外部库存储在源代码控制中，但我希望这些外部库位于单个存储库中（不包含在每个单独的项目中），因为有很多库，而且它们很大.

现有艺术

This question addresses the problem but no one answered to it directly. (How do I organize my Git repo [better title appreciated])

This pretty well describes a similar situation, but no dice. (Git, sub-repos & external libs for web development - best strategy once and for all?)

This definitely answers the question, but uses submodules. (Best Practice for Git Repositories with multiple projects in traditional n-tier design)

Git Slave sounds great, but I'd prefer to not add another git tool to our repertoire as git is new to us.

这是我目前的想法。

my coding dir/    
    app1/
        .git/
        src/
        com/
        ...
    app2/
        .git/
        src/
        com/
        ...    
    ext libs/
        .git/
        server crap/
            apache tomcat 7.0.123/
                ...
            apache cxf versionnumber/
                ...
        util crap/
            someones really great util lib-1.0/
                ...

然后在配置或类似文件中会有一个 $PATH 变量指向 lib 目录。

更多想法

• 我们没有基础架构工程师，因为我不想 每次有人需要添加或更新库时随时待命，我想害羞 远离 git 子模块，因为它看起来很粗糙。我很高兴将来能做到这一点，但我们只是 从 git kolaid 开始我们的饮料。
• 我现在也很乐意使用子模块，如果有人可以向我指出一个清晰的解释它是什么以及一个清晰的教程如何使用它，这样我就可以将此信息传递给我的同行。我不想让每个人在我们刚刚开始使用 Git 的时候阅读关于高级主题的两个小时的文档。
• 最好将 lib 存储库的版本与应用程序存储库的版本链接起来。

再一次，我可以摆脱我的反子模块情绪，但我能找到的教程已经过时和/或令人困惑的事实令人沮丧。这对于任何工程师来说都是一个简单的过程，并且易于撤消。我们不是 git ninjas！

最后，我不知道这是否重要，但我们都在 unix 上，而且一直都是 java。

提前致谢！

2012 年 3 月 1 日更新

我要让小莱纳斯·托瓦兹哭了。

我一直在做大量的研究，我的结论是如果你已经是一个 git ninja，子模块是很棒的。所以，也就是说，我会做错事并在每个 git 项目中创建一个 libs 目录。为什么？它更容易，并且比我们目前正在做的事情有了很大的改进。它还假设 git 知识的门槛要低得多。有一天，当我们对 git 的基本和中级概念（补丁？重写历史？高级分支？）都非常熟悉时，我们可能会转向子模块。就目前而言，我不想让我的工程师因为太多的咀嚼而让他们失败。

希望从现在到我们准备好转向“正确的方式”时，子模块会少一些。

Answer 1

子模块就是为此而设计的。请学习它们。 ProGit.org/book 是一个很好的资源。请参阅第 6 章第 6 节（我已经记住了）。

如果您有任何其他问题，我很乐意通过 twitter/电子邮件提供帮助。与我在这里使用的 id 相同。