Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: Git software Management
Is it a good idea manage difference edition with my versioncontrol (git) and
create one branch for my 'pro' other for my 'free' edition?
For bigfixes i could merge my bugfix-branch into free and pro branch and some features only merge into pro.
 
Or is there are a better way?
Posted 14-Dec-12 10:16am

1 solution

Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

I'm pretty much sure that using Revision Control branching feature for such things is a bad idea. I have a very different approach and can argue strongly in its favor.
 
Even with new generation of Revision Control system which is designed to allow decentralized repository and therefore having very strong branch merge features (as you know, Git is one of such systems), branches are designed to combine independent development and collaboration, but not to isolate different versions of the same project. For example, it's very good to have a possibility to have experimental branch, which you can later merge with the main trunk, fully or partially. Here, the separate "version" of software is conceptually temporary (even if the "temporary" condition can last many years) and well motivated. It does not violate more fundamental principle "Single Source of Truth" (http://en.wikipedia.org/wiki/Single_Source_of_Truth[^]). The same goes about "bugfix" branch, with somewhat weaker motivation.
 
Your "pro" and "free" branches are conceptually permanent; they are the two incarnations of the same very product. Using two or more different branches for different incarnations is the violation of the principle mentioned above, and can hurt you later badly.
 
Here is what I can suggest: move the separation between the "free" and "pro" version from the Revision Control to the build process. You should always have the common code base for all your version sitting in the main trunk. The version branches should be used to "freeze" development of the versions; and they should never be further modified, as any modification should be designated as a separate version. Your incarnations should become a different build options. (I don't know what do you use, but I did such things using MSBuild project schema which allows any kinds of customization.)
 
Also, you should separate the build and deployment. In other words, you should have two distinct stages: one stage builds absolutely everything (incrementally of from scratch — this is a separate option), both "free", "pro" and whatever else. Another stage should form a deployment package which consists of some subset of the content of your output directories, plus some configuration data. When you segregate these two distinct steps, your classification into different reincarnation of the product will come out quite naturally.
 
Good luck,
—SA
  Permalink  
v3

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 375
1 Sergey Alexandrovich Kryukov 329
2 CPallini 260
3 DamithSL 214
4 Maciej Los 197
0 OriginalGriff 5,455
1 DamithSL 4,457
2 Maciej Los 3,885
3 Kornfeld Eliyahu Peter 3,480
4 Sergey Alexandrovich Kryukov 3,115


Advertise | Privacy | Mobile
Web04 | 2.8.141216.1 | Last Updated 14 Dec 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100