1

We have a structure similar to Best Practice for Git Repositories with multiple projects in traditional n-tier design, with the following repositories:

  Shared
  ProjA
  ProjB

Where ProjA and ProjB are developed by separate teams of 2-3 people, using and sometimes contributing to Shared.

We thought of a simple model that doesn't require subtree or submodules, due to so many scares we read about those 2. Can you review and let us know if such a thing would work?

  • Each Proj and also Shared each live in a separate repo, following the gitflow model
  • Jenkins will build with the latest from the develop branch of all 3 repos
  • release.sh of a Proj would merge to master of both Proj and Shared, create a tag on both, and Jenkins would build and deploy from master.

Can this work? Keep in mind we're only 8 people, and we're just migrating into git, so we would like to keep stuff as simple as possible, so if we can avoid the learning curve of submodules and subtree, we would be happier. Or would we?

Community
  • 1
  • 1
ihadanny
  • 4,377
  • 7
  • 45
  • 76
  • What's wrong (or *scary*) about submodules? – Michael Wild Feb 26 '13 at 10:12
  • google provides many flames about this subject. E.g. "Now that you’ve seen the difficulties of the submodule system", out of http://git-scm.com/book/en/Git-Tools-Subtree-Merging – ihadanny Feb 26 '13 at 22:45
  • The concerns listed in there (i.e. the section before the one you referred to) are mainly issues with discipline. You **don't** do any work in the submodule. It's an external dependency, after all. But if that doesn't suit your workflow or needs, something else is called for. – Michael Wild Feb 27 '13 at 06:08

2 Answers2

1

It can work, provided that ProjA and ProjB keep somewhere (either in a versioned text file or as git notes) the exact references of Shared.

The idea behind a build scheduler is reproducibility: such a tool need to be able to reproduce the exact configuration (i.e. list of SHA1 references) used for a given build.
That allows to re-visit a build later on.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • So, whenever the build machine (jenkins) builds projA, it will keep the both the tag revision of projA and the tag revision of Shared, right? it doesn't have to be stored inside ProjA like in the submodules model, agree? – ihadanny Feb 26 '13 at 22:43
1

I feel your issue isn't git structuring, but projects' dependencies, for example SVN wouldn't make your life easier.

If you have two projects depend on a shared project I believe you shouldn't escape specifying that.

What if someone from Team B changes shared right before the release of Project A? You might get an unwanted change into project A.

To overcome that you should use project versioning, here git submodules comes to the rescue, the submodule is a dependency between project X and a specific point in time of shared.

An alternative to git submodules is artifacts version aware dependencies, in most (all?) modern languages you can do that. For example in Java, you'd use maven/ivy/gradle to define the project dependencies. (You'll need to upload shared to some artifacts repository)

I wouldn't say the alternative is simpler than git submodules, however it is the (must?) way to go when the project's structure is getting more complex with many artifacts depend on each other.

LiorH
  • 18,524
  • 17
  • 70
  • 98
  • Thanks! Personally I think that artifact repositories like maven are for sharing binaries between remote teams. When a developer works and changes both `ProjA` and `Shared`, he'll like to compile them both from his workspace, and use the local compiled version of both of them. Publishing a maven artifact for inter-team work between 8 people is an overkill for my taste. Will give the submodules a go however! – ihadanny Mar 02 '13 at 22:16