Git branching for new product variation

Question

I\'m using git to manage a repository I\'m working on.

the master branch is the \"main\" project. However, I\'m also working on a parallel product that is s

Answer 1

The effect git submodules achieve is exactly what you want: a body of common code on which multiple projects depend, with fixes to the common code shared among all the dependent projects. Submodules achieve the effect by separating out the history for the shared code, but that's just mechanics -- and once you see it, you'll understand it's the naturally correct solution.

The submodule command itself exists to keep track of some finicky housekeeping details (ordinarily, you can rm -rf * in a repo and not lose any committed state, but that's not true with nested repos so the command ordinarily hoists submodule .git dirs; things like that), but the submodule itself is nothing but a nested repository with its own history. If you cd into it, git commands don't even know it's a submodule of anything, because they don't have to care: being a submodule is just how the repo's being used, not anything intrinsic to the repo itself.

  git init projectA
  cd projectA
  touch A            # now there's a file at the projectA root,
                     # but the projectA repo doesn't know about it
  echo 'this content is in file "A" at the projectA root'> A
  git add A          # content recorded, the index points to it
  git commit -m'A'   # now projectA repo has a permanent record of the indexed state


  git init projectInner  # now there's an entire repo at the projectA root,
                         # but the projectA repo doesn't know about it 
  cd projectInner
  echo "Inner content" > Inner   # a file at the inner repo, no repo knows about it
  git add Inner                  # content recorded, the inner repo's index records it
  git commit -mInner             # the inner repo has a permanent record


  cd ..
  git add projectInner   # now the projectA repo knows about the inner, the content is recorded ...
  git commit -mInner     # and now the projectA repo has a permanent record

git adding an actual repo means recording its current state, just as for adding a file or a directory, but while the recorded state of a file is its entire contents, and the recorded state of a directory is the recursive state of all its (tracked or un-ignored) contents, the recorded state of a repo is simply its HEAD commit's SHA -- everything else already being recorded in that repo itself.

The payload here is that a git submodule is simply a nested repo, that it turns out a nested repo can be a very useful thing to have. As with the rest of git, what the submodule command is actually doing is brutally simple, all the apparent complexity is in implementing what's most convenient in all the different situations in which it is so useful.