Git branching for new product variation

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 similar but not the same as the main product. It lives in a branch called newproject.

  • Moving projects from PVCS into Git
  • Exclude some files from inter-branch merges in git
  • Git vs SVN - Network Performance (for backup)
  • How to check the differences between local and github before the pull
  • Do you push every single commit?
  • Where on the server does Git store files?
  • The code base is very similar between the two, but newproject is more stripped down, and has some core changes. However, tons of the window dressing stuff, like CSS, javascript, etc. are the same between the two branches.

    On the other hand, I’ve deleted lots of files in the newproject branch that still exist in master.

    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 master into 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 master.

    Is there a way to handle this situation?

  • Create remote repository from local files that are already on a local repo
  • Cannot Git Push from Xcode 5 using my user name
  • Merge status lost when stashing
  • new git user using netbeans support unable to pull latest commit from remote repository
  • Undo a git commit + git branch <branchname> — with a twist
  • Can't invoke git-svn from command line
  • 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.

    Git Baby is a git and github fan, let's start git clone.