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?

Reputation: 4483

Simple gitflow model with multiple repositories without submodules/subtree?

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?

Upvotes: 1

Answers (2)

LiorH

Reputation: 18824

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.

Upvotes: 1

VonC

Reputation: 1329092

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.

Upvotes: 1

Simple gitflow model with multiple repositories without submodules/subtree?

Answers (2)

Related Questions