Can I organize Git submodules in a flat hierarchy?

问题

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.

回答1:

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)

回答2:

I have run into a similar problem (which oddly seems to not be common). Another tool that you may want to consider is Google's repo. You can use this tool to reproduce flat the flat structure you require via a configuration file. Some of the pros and cons are covered in the second link provided by the previous answer.

My core issue with this solution is that each script needs a bare git repository. Ideally, you would want the script for reproducing your directory structure to reside in the top-level repo, but as of this time, that functionality is not available.

来源：https://stackoverflow.com/questions/27721074/can-i-organize-git-submodules-in-a-flat-hierarchy

标签

.net

git

git-submodules