git - 将代码组织到Git子模块中

Question

我想知道Git子模块是否合适
组织我目前在RCS下保存的一些代码，如果
因此，应该如何组织子模块。

模块概述

假设我有一个库模块集合（也许是库，也许是
单个库的一部分；这是一个需要讨论的项目）。
假设其中一些模块是基本模块，而其他模块取决于
在基本模块上。
所有这些模块都打算供其他包装使用
软件（程序），可能包括适当的
选择这些软件包作为子模块。

具体来说，库模块为：


stderr-标准化的错误报告例程（不依赖于
其他模块）。
filter —文件过滤器程序（如grep或cat）：使用
stderr。
debug —调试跟踪支持：使用stderr
phasedtest —单元代码测试：使用filter，debug和
stderr直接。
rational-使用的有理数算术包
phasedtest用于其测试代码，但独立于phasedtest
以及其他相关性。


许多其他程序使用stderr。
许多使用它们的人还使用filter（以及所有使用
filter也直接使用stderr），但是有很多
确实使用stderr但不使用filter的程序。
有些程序使用debug;基本上所有这些程序也使用
stderr直接，但他们可能会或可能不会直接使用filter。
使用phasedtest的单元测试程序可以使用也可以不使用stderr，
filter和debug直接使用（与stderr相比，
其他），但是phasedtest本身需要它们，因此此类程序始终
间接使用这些模块。
有些程序可能使用rational。通常他们也会使用stderr
（我写的几乎所有内容都使用stderr），但是这些程序没有
通常，直接直接使用phasedtest。

只是为了澄清：目前，这些潜在的Git模块和
子模块根本不在Git中；他们中的大多数人都广泛（10-30
RCS（Y2K之前的SCCS）的历史记录，将在
他们过渡到Git。
目的是在适当的时候将所有存储库放入GitHub。
通常，这些模块都相当稳定。
它们确实得到修订或扩展，但不一定每年。
有时，三年或更长时间没有改变。
我有一个构建/分发系统，其中组成什么的文件
可能成为子模块被拉入更大的分布
程序准备发布时。
在正常（单人）开发过程中，材料生活在
库，其中数百个源文件内置到单个（静态）中
库（在$HOME/lib中）和单个标头目录（在$HOME/inc中，
与/usr/include相似或完全独立
/usr/local/include）。

我正在寻求使结构“正确” —足够正确，以至于我
在将它们过渡到Git之前，我不会后悔。
我仍然有版本标记和标签问题需要解决；那是一个
整个单独的bag'o'worms，而不是这个问题的一部分。

子模块应如何组织？

根据我对子模块的了解，似乎：


stderr应该在其自己的存储库中。
filter应该位于自己的存储库中，并以stderr作为子模块。
debug应该位于自己的存储库中，并以stderr作为子模块。
phasedtest应该位于自己的存储库中，并具有：


debug作为一个子模块
filter作为一个子模块
但它是否还应包含stderr作为直接子模块，或者
是否应使用嵌套子模块中的stderr版本
（stderr内部的debug和/或内部的stderr
filter）？

rational应该位于自己的存储库中，并且phasedtest
子模块（以及附带的任何子子模块组织
phasedtest）。


出现的问题


filter和debug独立地需要stderr子模块
（但它们不太可能严重依赖任何特定条件
stderr的版本-发行版级别上几乎所有可用的版本
10个就足够了）。因此，它们都需要在子模块中使用stderr版本。
多少个图书馆：应该有？选项包括：


是否应该有三个独立的库：libstderr，libdebug，
和libfilter？
或者libfilter应包含stderr中的材料，并且
libdebug应包含stderr中的材料（两个
库）？
还是应该有一个复合库libjlss
stderr，debug和filter中的元素？
如果共享库而不是共享库，答案是否有所不同？
静态的？

phasedtest代码是否应组织为第四个库
包含模块stderr，filter和debug作为子模块
（这样，stderr将出现3次，一次是直接
依赖关系，并且是debug和filter的依赖关系的两倍），或者
是否应该是一个较小的库，需要与这三个库链接
单独的依赖库？
由于rational模块仅需要phasedtest进行测试，
它不会安装phasedtest一个或多个库。
但是它将需要它们可用于测试。
如果需要预安装的phasedtest库（库），
还是应该是独立的并且具有必要的代码
测试作为其分发的一部分？
使用rational的程序也可能会使用stderr（可能会），
但可能会或可能不会使用debug和filter，并且可能是
除了自己进行单元测试外，不太可能使用phasedtest
组件。


主要问题


Git子模块是正确的方法，还是我应该在寻找
替代组织？
假设Git子模块合适，那么Git将如何
存储库组织得最好吗？


辅助问题


储存库是否有最小的合理大小？
一个存储库中是否有最大数量的子模块？
一个子模块是否是多个子模块的子模块是否重要
一个存储库使用的子模块数量？
子模块有常规的目录结构吗？
所有目录都直接位于顶层目录中，或某些位于
根目录或准随机中的标准目录名称
超级项目目录层次结构中的位置？
是否有我没有发现的明显陷阱？

Answer 1

您的前两个问题（“ git子模块是否合适？”和“我应该如何组织它们？”）实际上并不适合Stackoverflow：答案将主要是见解，而且很难确定任何一个答案都是“正确”。

您的辅助问题要稍微解决一些：


储存库是否有最小的合理大小？


不是，不是


一个存储库中是否有最大数量的子模块？


再说一次，没有，但是在创建带有数百个子模块的怪物库之前，请确保您首先熟悉使用它们的知识。人们对如何最好地管理子模块有不同的看法。 Here is one person花了一些时间思考的人。我不同意他的所有想法，但这至少是开始思考这个问题的一种方式。


单个子模块是否是单个存储库使用的许多子模块的子模块，这有关系吗？


并非如此，不是，尽管如果您在资源上散布着多个存储库实例，则可能会遇到版本偏斜的问题（例如，一个版本为A，另一个版本为B，另一个版本为C）。除非您非常小心。


子模块有常规的目录结构吗？所有目录都直接位于顶层目录中，还是位于根目录中标准目录中的某些目录中，或者位于超级项目目录层次结构中的准随机位置中？


没有，但是通常您会选择适合自己的东西并坚持下去。我见过许多将子模块放置在lib或modules目录中的项目，而其他一些项目确实将它们放置在顶层。


是否有我没有发现的明显陷阱？


请记住，当作为子模块签出时，当前HEAD由父存储库管理。也就是说，如果您cd进入子模块，进行更改，将其推送，然后在父项目中运行git submodule update，您将把子模块的本地副本回滚到记录在父模块中的任何提交。

出于这个原因，我通常将子模块视为存储库的只读实例，这些子模块只能通过运行git pull进行更新（随后在父存储库中进行后续提交）。我仅在存储库的独立签出中编辑文件。

在将新更改拉入父存储库后，您需要进行培训以定期运行git submodule update（以防这些更改包括子模块的新版本）。