Question

TL; DR版 - 我希望在单独的存储库中跟踪多个独立应用程序的活动开发，但是所有这些应用程序都显示，好像它是在下管理的使用不同名称的单个源树，如下所示：

/root                      --> REPO_1
  /app1                    --> REPO_2
  /app2                    --> REPO_3
  /lib                     --> REPO_4

我尝试了git子模块，但由于它们与特定的提交相关联，因此它们不能满足我的需要。只需将存储库克隆到子目录中，就可以从我们的架构师那里得到大拇指（然后建议子模块）。还有其他选择可以满足我的需求吗？

Peter Jackson LotR扩展蓝光版：我们正在从CVS迁移到Git，作为自动化代码构建和部署的更大努力的一部分，我陷入了这样的境地：我需要一些指导。

我们有40多个不同的应用程序都属于同一个保护伞，组织如下：

/root_src_dir
  /app1dir
    /Makefile.in
    /src1.cpp
    /src2.cpp
    ...
  /app2dir
    /Makefile.in
    /src1.cpp
    /src2.cpp
    ...
  configure.in
  /lib
    /Makefile.in
    /lib1
      /Makefile.in
      /src.cpp
      ...
    /lib2
      /Makefile.in
      /src.cpp
      ...
  Makefile.in

lib子目录包含所有不同应用程序使用的公共库代码。否则，应用程序不共享代码。它们在很大程度上是相互独立的。它们彼此独立部署，库代码独立部署为.so个文件。一个的提交历史不应该影响另一个的提交历史。

要构建，我们会在autoconf中的configure.in文件上运行root_src_dir;然后，我们在与build相同的级别创建一个root_src_dir目录，并从那里运行生成的configure脚本。然后configure脚本创建构建目录树并在该树中生成相应的Makefile。

简而言之，从root_src_dir/configure目录运行build后，我们得到以下信息：

/build
  /app1dir
    Makefile
  /app2dir
    Makefile
  /lib
    /Makefile
    /lib1
      /Makefile
    /lib2
      /Makefile

库子目录的Makefile在includes下创建一个build子目录，并将所有库文件头复制到其中。

在当前的CVS配置下，所有内容都集中在root_src_dir的单个存储库下。

作为此迁移的一部分，我希望将每个应用程序移动到其自己的单独存储库中，原因如下：

申请在很大程度上是相互独立的;他们共享的唯一代码是公共库代码（将保存在自己的独立存储库中）;
自动配置管理工具（我们不拥有）假设每个应用程序都保存在一个单独的存储库中;
构建整个世界需要一段时间，而且不需要部署单个应用程序更新;
我希望能够跟踪每个应用程序的版本，并将它们保存在单独的存储库中，这样可以更轻松。

但是，我想现在使用相同的目录结构，因为：

我不想通过几十个特别神秘的Makefile来改变路径和依赖关系;
我不想为我们的开发人员显着改变流程;
我希望保持相同的开发命名约定（自动CM工具使用... 繁琐的 ...命名约定）。

所以，我尝试了一些实验。现在我有这样的事情：

/STUPID_ACM_NAMING_CONVENTION_ROOT_DIR
  /configure.in
  /Makefile.in
/STUPID_ACM_NAMING_CONVENTION_APP1
  /Makefile.in
  /src.cpp
  ...
/STUPID_ACM_NAMING_CONVENTION_APP2
  /Makefile.in
  /src.cpp
  ...
/STUPID_ACM_NAMING_CONVENTION_LIB
  /Makefile.in
  /lib1
    /Makefile.in
    /src.cpp
    ...
  /lib2
    /Makefile.in
    /src.cpp

作为第一遍，我将STUPID_ACM_NAMING_CONVENTION_ROOT_DIR克隆到名为root_src_dir的目录，然后在root_src_dir下我使用旧的命名约定将每个应用程序存储库克隆到子目录：

$ git clone $REPO_HOME/STUPID_ACM_NAMING_CONVENTION_ROOT_DIR root_src_dir
$ git clone $REPO_HOME/STUPID_ACM_NAMING_CONVENTION_APP1 root_src_dir/app1dir
$ git clone $REPO_HOME/STUPID_ACM_NAMING_CONVENCTION_APP2 root_src_dir/app2dir
$ git clone $REPO_HOME/STUPID_ACM_NAMING_CONVENTION_LIB root_src_dir/lib

这＆＃34;工作＆＃34 ;;我能够以同样的方式建造;更好的是，我写了一个脚本，只需要克隆根目录，库目录和应用程序目录来进行构建（不需要复制整个源代码树来构建单个应用程序）。我可以在自己的存储库中跟踪每个应用程序，并以有意义的方式标记它。推动和拉动似乎有效，但是在分支和合并方面并没有发挥很大作用，但我们无论如何也不会对此感到满意。但是，我被告知这是一个不太理想的解决方案，因为CM小组不了解我们的目录结构，因此他们无法在没有我们输入的情况下（或脚本）重现这一点）。

足够公平。所以我玩了子模块。我已经看过很多围绕子模块的网络警告的文章，现在我理解为什么。将子模块附加到父项目时，您将附加特定的提交;您可以更新应用程序存储库，但是当您克隆父项目时，这些更改不会反映在子模块中。看起来子模块非常适合跟踪不会发生很大变化的外部依赖项，但不适合跟踪活动开发。

因此，克隆到子目录中（建筑师不喜欢它），子模块已经出局（不做我需要的）。我还有其他选择吗？我如何才能获得为每个应用程序使用单独的存储库的好处，同时最大限度地减少对当前构建过程（假设特定目录结构）的影响？我们是一个小团体（大约6名开发人员），代码中没有那么多的流失，我们通常不会重叠开发，我们不需要一堆不同的功能分支机构。

Git - 将单独的存储库映射到源树

0 个答案: