我可以在平面层次结构中组织Git子模块吗? [英] Can I organize Git submodules in a flat hierarchy?

问题描述

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

核心(库):无依赖性

测试(库):对Core的依赖

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

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

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

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

  src核测验序列化客户 

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

我想将这些项目分成几个存储库，以便可以独立进行处理(尤其是因为推送到GitHub并保持干净的历史记录).因此，我阅读了有关 Git子模块进行组织的信息./p>

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

据我所知，子模块成为父仓库中的一个子目录，被视为其独立仓库.因此，如果我介绍了三个用于序列化，测试和核心的子模块，以及其中两个具有各自子模块的子模块(即依赖于Core的子模块)，那么我将得到这样的结果:

  src核测验核序列化核测验客户 

是否可以保留平面目录结构?我正在寻找Git子模块正确的东西吗?还是我应该为Core，Testing，Serialization和Client选择不同的Git存储库，并将它们全部组织在父Git存储库中(这会添加另一个存储库只是为了整理其他存储库)?Git Subtree是可行的选择吗?

我的总体目标是:

• 在一个解决方案中实际上驻留在不同存储库中的客户端和库代码上进行无缝工作.
• 将库推送到GitHub，但在封闭源代码下保留客户端代码.
• 为客户端解决方案提供轻松的构建和部署，即，您只需要(递归)克隆(正确的)存储库，构建代码，然后一切都将运行(客户端，服务，自动化测试).

如果您已阅读完所有这些文本，谢谢.如果您能回答这个问题，请多多关照.

解决方案

我正在寻找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 )

I currently working on a .NET project and several .NET libraries which have the following interdependencies (simplified version):

Core (library): no dependencies

Testing (library): dependencies to Core

Serialization (library): dependencies to Core, Testing

Client solution: dependencies to Core, Testing, Serialization

My goal is to move as much code to the libraries as possible so that I can reuse them in different client solutions.

Currently, all these different projects are part of a single Git repository. They reside in the following directory structure:

src
    Core
    Testing
    Serialization
    Client

i.e. each project resides next to all other projects inside the src folder, forming a flat hierarchy.

I want to split these projects up into several repositories so that they can be worked on independently (especially because of pushing to GitHub and maintaining a clean history). Therefore, I read about Git submodules to organize them.

My actual question is: can I use Git submodules and maintain a flat directory hierarchy?

As far as I understand the text, a submodule becomes a subdirectory in the parent repo that is treated as its an independent repo. Thus if I introduce the three submodules for Serialization, Testing and Core, and two of these submodules having submodules on their own (namely dependecies to Core), I would end up with something like this:

src
    Core
    Testing
        Core
    Serialization
        Core
        Testing
    Client

Is there a possibility to retain the flat directory structure? Are Git submodules the right thing I'm looking for? Or should I maybe go for different Git repositories for Core, Testing, Serialization and Client and organize them all in a parent Git repo (which would add another repo just to oranize the other ones)? Is Git Subtree a viable option?

My overall goals are:

• Work seemlessly on client and library code that actually resides in different repositories within one solution.
• Push libraries to GitHub but retain client code under closed source.
• Provide easy build and deployment for the client solutions, i.e. you just need to (recursively) clone the (correct) repo, build the code and everything just runs (client, services, automated tests).

Thank you if you've been reading through all this text. And thank you so much in advance if you can even answer this question.

解决方案

Are Git submodules the right thing I'm looking for?

If you want to "Work seemlessly on client and library code that actually resides in different repositories within one solution" then submodules may not be the way to go.

Also, "Provide easy build and deployment for the client solutions, i.e. you just need to (recursively) clone the (correct) repo, build the code and everything just runs" is achievable, but will require some discipline.

Submodules are a good way of including a particular commit of another repository, providing stability and isolation of development. In git, a submodule is a detached head, so if you plan on making frequent changes, you will have to make sure that you always check out a branch. There are a few quirks to them that will require a set of git aliases and programmer discipline to avoid big mistakes and frustration.

For a review of the drawbacks of submodules in some cases (and ways of shooting yourself in the foot), see 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/

For similar applications, I use giternal (https://github.com/patmaddox/giternal) for including dependencies that i know I will sometimes commit to. (See this blog post for a brief introduction: http://www.rubyinside.com/giternal-easy-git-external-dependency-management-1322.html)

这篇关于我可以在平面层次结构中组织Git子模块吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！