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

时间:2014-12-31 12:21:10

标签: c# .net git git-submodules

嘿伙计们,

我目前正在研究.NET项目和几个具有以下相互依赖关系的.NET库(简化版):

核心(库):没有依赖

测试(库):依赖于Core

序列化(库):对Core的依赖,测试

客户端解决方案:对Core,Testing,Serialization的依赖

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

目前,所有这些不同的项目都是单个Git存储库的一部分。它们位于以下目录结构中:

src
    Core
    Testing
    Serialization
    Client

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

我想将这些项目拆分为多个存储库,以便它们可以独立工作(特别是因为推送到GitHub并保持干净的历史记录)。因此,我阅读了Git submodules来组织它们。

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

据我理解文本,子模块成为父repo中的子目录,被视为独立的repo。因此,如果我引入序列化,测试和核心的三个子模块,以及其中两个子模块本身具有子模块(即依赖于核心),我最终会得到这样的结果:

src
    Core
    Testing
        Core
    Serialization
        Core
        Testing
    Client

是否有可能保留平面目录结构? Git子模块是我正在寻找的正确的东西吗?或者,我是否可以为Core,Testing,Serialization和Client寻找不同的Git存储库,并将它们全部组织在一个父Git仓库中(这会添加另一个仓库以便对其他仓库进行oranize)? Git Subtree是一个可行的选择吗?

我的总体目标是:

  • 在一个解决方案中实际驻留在不同存储库中的客户端和库代码上无缝工作。
  • 将库推送到GitHub,但保留客户端代码在封闭源下。
  • 为客户端解决方案提供简单的构建和部署,即您只需(递归地)克隆(正确)repo,构建代码以及运行的所有内容(客户端,服务,自动化测试)。

谢谢你,如果你一直在阅读所有这些文字。如果你能回答这个问题,请提前感谢你。

2 个答案:

答案 0 :(得分:2)

  

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

如果您希望“在一个解决方案中实际驻留在不同存储库中的客户端和库代码上无缝工作”,则可能无法使用子模块。

此外,“为客户端解决方案提供简单的构建和部署,即您只需要(递归地)克隆(正确)repo,构建代码并运行所有内容”是可以实现的,但需要一些纪律。

子模块是包含另一个存储库的特定提交的好方法,可提供稳定性和开发隔离。在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

答案 1 :(得分:1)

我遇到了类似的问题(奇怪的是,这似乎并不常见)。  您可能需要考虑的另一个工具是Google的repo。您可以使用此工具通过配置文件再现所需的扁平结构。前一个答案提供的第二个链接涵盖了一些优缺点。

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