2

We are currently refactoring code to be shared among different projects in our company. This shared code will be included in other projects as a Git submodule.

One thing we're worried of is breaking changes introduced to the super project from the submodule at certain stages of the project (e.g: a point where we should be stable / code freeze).

I have never worked with submodules before, but according to what I know, a submodule references a particular commit in another repo, so you're basically OK as long as you don't update the submodule in the project.

Another teammate of mine suggested that whenever we enter a "stable phase" of the project (e.g: finish dev), we should create a branch of the submodule and point to that. I think this is an overhead and seems wrong (a shared project shouldn't be version-locked with other projects that use it).

So, to sum it up, my questions are:

  1. Is there anything at all that should be done to protect a super project from submodules updates (breaking changes) ?
  2. Is there a known workflow where a super project that goes into a stable phase, also creates a new branch of its submodules to point to? (a link would be great).
lysergic-acid
  • 19,570
  • 21
  • 109
  • 218

1 Answers1

2

Is there anything at all that should be done to protect a super project from submodules updates (breaking changes) ?

No: whatever modifications are done in a submodule (and push to its upstream repo) would not affect the parent repo: it would still reference the same gitlink (a special entry in the index of the parent repo).

Is there a known workflow where a super project that goes into a stable phase, also creates a new branch of its submodules to point to?

No: a submodule is a fixed SHA1.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250