git - 版本控制 : Managing Common Component Source

Question

如何在 DVCS 中管理公共(public)库源代码？

目前，我的团队使用 Perforce 来管理我们的软件项目。使用 Perforce 的“工作区映射”功能，我能够轻松地将公共(public)库源映射到开发应用程序目录，从而使源管理和开发项目工作之间的转换保持透明。例如，存储库看起来像这样:

---

单片机树结构

• 根
  • 应用程序
    • 论坛网站
    • 管理工具
  • 常见的
    • 事件记录器
    • json.解析器
  • 数据库
    • 用户
    • 网站配置

由于出色的 P4 映射功能，我们的开发人员可以使用工作区映射以最有意义的形式为他们处理的项目提取一整套源代码。典型的开发项目文件夹可能如下所示:

---

开发项目文件夹

/projects
    /FALL-2009
        /ForumSite
            /deps
                /event.logger
                /json.parser
        /AdminTool
            /deps
                /event.logger
                /json.parser
        /Users-db
        /SiteConfiguration-db
    /FALL-2009-PATCH-01
        /json.parser
        /SiteConfiguration-db
    /FALL-2009-PATCH-02
        /AdminTool
            /deps
                /event.logger
                /json.parser
        /SiteConfiguration-db

当开发人员在他/她的任何组件或应用程序中编辑源代码时，更改将映射回正确版本点的正确源代码控制目录。这对开发人员来说是透明的，减少了管理的复杂性和设置新项目的时间。

我正在研究 Git、Bazaar 和 Mercurial 作为 Perforce 的潜在替代品。任何人都可以深入了解 DVCS 世界中如何处理通用组件源吗？

Answer 1

在 Git 中，您将使用 git submodule为此目的。

Git 子模块存储为对来自另一个存储库的修订的引用，以及一个提供用于查找其他存储库的 URL 的文件。当您执行 git submodule update 时，Git 将克隆所引用存储库的副本(或者您可以将其配置为指向位于不同 URL 的同一存储库的不同副本，因为它是 DVCS因此，包含引用修订的存储库的任何克隆也将有效)，然后检查引用的修订。

遗憾的是，它并不像人们希望的那样无缝。在父存储库中 checkout 新修订版实际上并没有 checkout 子模块；你需要做一个明确的 git submodule update 来完成这个。我们尝试包装 git pull; git submodule update 作为单个命令，但还有许多其他命令(例如 git rebase)涉及 check out 文件，这会让您陷入困惑状态，因为它们不也更新子模块。一旦您熟悉了子模块的工作方式，一切都会迎刃而解，但会带来一些摩擦。