Git branching for new product variation
I’m using git to manage a repository I’m working on.
master branch is the “main” project. However, I’m also working on a parallel product that is similar but not the same as the main product. It lives in a branch called
The code base is very similar between the two, but
On the other hand, I’ve deleted lots of files in the
newproject branch that still exist in
I don’t want to merge these projects back together, as is the typical case with branches where you create a branch to add a feature or fix a bug then merge back to
master— these branches will live independently permanently.
However, I still want to get any fixes from
newproject where there is still overlap / shared files.
If I simply do
$ git checkout newbranch $ git pull origin master
I get a boatload of conflicts since all the deleted files show up as conflicts since they still exist in
Is there a way to handle this situation?
2 Solutions collect form web for “Git branching for new product variation”
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.
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.