How to manage multiple versions of a project in Git
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.
- Similar program to Team Foundation Server
- GitHub recover deleted blocks of code
- When working with Eclipse, should I add the workspace to the source control?
- svn externals … yes or no?
- obtaining full file paths in git merge
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.
Thanks for the help.
2 Solutions collect form web for “How to manage multiple versions of a project in Git”
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
Git will only merge what has changed since you branched between
premium, ie your bug fix.
On another way to publish an hotfix both in
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.
- Working with a branch using
- “The Nuclear Squid
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
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.
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 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 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 wouldn’t be confused.
Hope that helps.