我可以在平面层次结构中组织 Git 子模块吗？

Question

我目前正在研究一个 .NET 项目和几个具有以下相互依赖性的 .NET 库（简化版）：

核心（库） ：无依赖

测试（库） ：对核心的依赖

序列化（库） ：对核心、测试的依赖

客户端解决方案：对核心、测试、序列化的依赖

我的目标是将尽可能多的代码移动到库中，以便我可以在不同的客户端解决方案中重用它们。

目前，所有这些不同的项目都是单个 Git 存储库的一部分。 它们驻留在以下目录结构中：

src
    Core
    Testing
    Serialization
    Client

即每个项目都位于src文件夹内的所有其他项目旁边，形成一个平面层次结构。

我想将这些项目分成几个存储库，以便它们可以独立工作（特别是因为推送到 GitHub 并保持干净的历史记录）。 因此，我阅读了Git 子模块来组织它们。

我的实际问题是：我可以使用 Git 子模块并维护平面目录层次结构吗？

就我理解的文字而言，子模块成为父仓库中的子目录，被视为独立的仓库。 因此，如果我引入序列化、测试和核心的三个子模块，并且这些子模块中的两个具有自己的子模块（即对核心的依赖），我最终会得到这样的结果：

src
    Core
    Testing
        Core
    Serialization
        Core
        Testing
    Client

是否有可能保留平面目录结构？ Git 子模块是我正在寻找的正确的东西吗？ 或者我应该为 Core、Testing、Serialization 和 Client 使用不同的 Git 存储库，并将它们全部组织在一个父 Git 存储库中（这会添加另一个存储库来整理其他存储库）？ Git Subtree 是一个可行的选择吗？

我的总体目标是：

• 在一个解决方案中实际驻留在不同存储库中的客户端和库代码上无缝工作。
• 将库推送到 GitHub，但在闭源下保留客户端代码。
• 为客户端解决方案提供简单的构建和部署，即您只需要（递归地）克隆（正确的）存储库，构建代码并且一切都刚刚运行（客户端、服务、自动化测试）。

感谢您阅读所有这些文字。 如果您能回答这个问题，那么在此先感谢您。

Answer 1

Git 子模块是我正在寻找的正确的东西吗？

如果您想“在一个解决方案中实际驻留在不同存储库中的客户端和库代码上无缝工作”，那么子模块可能不是要走的路。

此外，“为客户端解决方案提供简单的构建和部署，即您只需要（递归地）克隆（正确的）存储库，构建代码并运行一切”是可以实现的，但需要一些纪律。

子模块是包含另一个存储库的特定提交、提供稳定性和开发隔离的好方法。 在 git 中，子模块是一个独立的头，所以如果你打算频繁更改，你必须确保你总是检查分支。 他们有一些怪癖，需要一组 git 别名和程序员纪律来避免大错误和挫折。

有关子模块在某些情况下的缺点的评论（以及在脚下射击自己的方式），请参阅http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/ https ://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/

对于类似的应用程序，我使用 giternal ( https://github.com/patmaddox/giternal ) 来包含我知道有时会提交的依赖项。 （简单介绍见这篇博文： http : //www.rubyinside.com/giternal-easy-git-external-dependency-management-1322.html ）

Answer 2

我遇到了类似的问题（奇怪的是，这似乎并不常见）。 您可能要考虑的另一个工具是 Google 的repo 。 您可以使用此工具通过配置文件重现您需要的平面结构。 上一个答案提供的第二个链接中介绍了一些优缺点。

我对这个解决方案的核心问题是每个脚本都需要一个裸 git 存储库。 理想情况下，您希望用于重现目录结构的脚本驻留在顶级存储库中，但截至目前，该功能不可用。