在Git中为几个项目组织外部LIB

问题

我希望我的公司在源代码管理中存储所有包含的外部LIB，但我希望这些外部LIB在单个回购中（不包括在每个单独的项目中），因为有很多LIB，而且它们都很大

现有技术

这就是我目前的想法。

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 dir

更多想法

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

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

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

提前谢谢

2012年1月3日更新

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

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

---

希望从现在起到我们准备好走“正确的道路”时，子模块将不再那么麻烦。

子模块就是为此而设计的。请学习它们。org/book是一个很好的资源。参见第6章第6节（我已将其牢记于心）

---

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

我们对git非常陌生，子模块上的progit教程只有5页，这一事实让人感到厌烦。如果有一个更简洁、清晰、最新的教程，我很乐意使用子模块，[我知道这个视图是短视的]，但似乎开销不值得努力。请证明我错了。我可能会晚一点打你，它很强大。您是否希望在不阅读手册的情况下使用某些东西？阅读教程并稍加练习并不需要那么长时间。如果你选择在这里节省时间，你将在未来和长远浪费大量时间。省一便士，赔一美元。我也很关注gtalk。此外，git irc频道上还有数百人。所有人都愿意日夜牵着你的手完成任何任务。希望您能将您的流程发展为我们所拥有的流程：是的，我们对每个功能进行分支。我自己并不担心阅读手册。我会很高兴的。我担心说服一组工程师这样做和/或自己做一个教程/研讨会，因为我不知道git的来龙去脉。这让我害怕。值得关注的是，没有一个快速而肮脏的子模块介绍来补充冗长而详尽的子模块介绍。我想这意味着我必须自己写一本；）不要成为瓶颈。让其他人参与进来。