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.

Answer 2

after you have branched, you will be able to do a git rebase master on your new project branch to move it's separation point up to the HEAD of the master branch. what this will do is re-apply all of the diffs (which will be very easy and possibly have no major, if any, conflicts since most of the files are no longer in the newproject branch) from the newbranch separation point on top of the changes done to the master branch. Since the newproject commits include the removal of those files and other changes, everything should go smoothly (with hopefully not too many conflicts). Check out the rebasing info listed under the de-facto git book linked here.