2

问题

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

现有技术

这个问题解决了这个问题，但没有人直接回答。（如何组织我的 Git 存储库 [更好的标题赞赏]）

这很好地描述了类似的情况，但没有骰子。（用于 Web 开发的 Git、子存储库和外部库 - 一劳永逸的最佳策略？）

这肯定回答了这个问题，但使用了子模块。（传统 n 层设计中具有多个项目的 Git 存储库的最佳实践）

Git Slave 听起来很棒，但我不想在我们的曲目中添加另一个 git 工具，因为 git 对我们来说是新的。

这是我到目前为止的想法。

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/
                ...

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

更多想法

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

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

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

提前致谢！

2012 年 3 月 1 日更新

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

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

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

4

1 回答 1

1

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

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

于 2012-02-24T19:29:54.593 回答