58

I have a project that is open sourced using git for revision control. Soon, I am going to release a premium hosted version of the project as well, but there will be changes made to the code specifically for the premium hosted version (performance, etc.), that should not exist in the open source version.

I want to avoid having two separate directories/projects, because if I fix a bug in the open source version, that bug is most likely in the premium hosted version as well. I don't want to make changes in two places.

What is the best way to manage this? Simply branching in git won't work right, because some files need to have 2 versions: an open source version and a premium hosted version.

double-beep
  • 5,031
  • 17
  • 33
  • 41
Justin
  • 42,716
  • 77
  • 201
  • 296
  • 2
    why was this question closed based on being opinion-based? what is an opinion when it comes to GIT? – Ayyash Jun 16 '21 at 06:13

2 Answers2

43

And yet, branching should work, and will allow you to maintain two separate versions.

If you have a bug which applies to the premium version, fix it on master, and merge it on premium branch.
Git will only merge what has changed since you branched between master and premium, ie your bug fix.
On another way to publish an hotfix both in master and premium would be to do it from the common ancestor: see "Git merging hotfix to multiple branches".

Update 2015: git 2.5 (July 2015) has replaced git-new-workdir presented below by the new command git worktree add <path> [<branch>].

For more, see "Multiple working directories with Git?".

Original answer 2012:

me-and mentions in the comments the command git-new-workdir.
See:

One solution to this is to simply create another local clone of your repository. Git automatically uses hard links when you clone locally, so cloning is very fast.
But there is one problem with this: You now have another, separate repository you need to keep up to date.

This is where git-new-workdir comes in.
Instead of doing a full-blown clone of your repository, it simply sets up a new working directory (with its own index) for you.
The actual repository itself is shared between the original and the new working directory. This means:

  • If you update one repository, the new commits are instantly visible in all other working directories as well.
  • Create a new commit or branch in one of your working directories, they’re instantly available in all working directories.

Note: Even though the commits are automatically there, Git won’t update the working copy if you’ve got the same branch checked out. You’ll have to do that for yourself.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    Can you give a workflow example. For example say I am working on master (open source), then need to make a change to premium. Do I simply `git checkout premium` then make my changes, then git commit. Then checkout master again? – Justin Aug 28 '12 at 06:08
  • @Justin yes, you can do that. Or you can even clone your repo twice: one in master, one in premium. That way, you can even develop in parallel. (and you can fetch changes from one local repo to another). – VonC Aug 28 '12 at 06:15
  • Yeah, what do you think is the better way, cloning the repo twice, and doing `git pulls` from each, or having one directory? – Justin Aug 28 '12 at 06:18
  • @Justin it depends on your development objectives: if you want to be able to test at any time any of those two versions, cloning is practical. But if you are mainly work on one of those version, and occasionally switch to the other, one repo is enough. – VonC Aug 28 '12 at 06:35
  • @Justin But other models exists: you can have only one local repo (with checkouts between branches), but two remotes repos for you to push to (one for pushing master, one for pushing premium): those remote repos can act as "guarded repos": see http://stackoverflow.com/questions/3209208/what-is-the-cleverest-use-of-source-repository-that-you-have-ever-seen/3209767#3209767 (from http://stackoverflow.com/questions/7330270/who-propagate-bugfixes-across-branches-corporate-development/7330826#7330826) – VonC Aug 28 '12 at 06:36
  • 2
    Rather than having multiple clones, I'd recommend taking a look at [`git-new-workdir`](http://nuclearsquid.com/writings/git-new-workdir/). – me_and Aug 28 '12 at 11:33
  • @me_and Interesting suggestion. I have included it in the answer for mroe visibility. – VonC Aug 28 '12 at 11:51
20

The use of worktree is best for this purpose.

In my case, I have two version of the same software that the basics are the same but each version has some different features.

So I create two worktree that means, create two relevant long-running branches beside the master.

$git worktree add -b version-silver ..\version-silver master
$git worktree add -b version-gold ..\version-gold master

Then I have:

$git branch
master  # base stuff here
version-silver # some normal features
version-gold # some better features

There is one repository, but I have 3 separate folders beside each other for each branch above. And make the common changes in the master. then merge it with both other versions.

cd master
vim basic.cpp
git add .
git commit -m "my common edit on basic.cpp"
cd ..\version-silver
vim silver.cpp
git add .
git commit -m "my specific edit on silver.cpp"
git merge master # here I get the basic.cpp latest changes for silver project
cd ..\version-gold
git merge master # here I get the basic.cpp latest changes for the gold project

Specific changes of each version will go in the corresponding folder as well, and the works on each project are isolated and IDE won't be confused.

Hope that helps.

vaheeds
  • 2,594
  • 4
  • 26
  • 36