Let's say that I am writing two different versions of the same software/program/app/script and storing them under version control. The first version is a free "Basic" version, while the second is a paid "Premium" version that takes the codebase of the free version and expands upon it with a few extra value-added features. Any new patches, fixes, or features need to find their way into both versions. 

I am currently considering using master and develop branches for the main codebase (free version) along side master-premium and develop-premium branches for the paid version. When a change is made to the free version and merged to the master branch (after thorough testing on develop of course), it gets copied over to the develop-premium branch via the cherry-pick command for more testing and then merged into master-premium.

Is this the best workflow to handle this situation? Are there any potential problems, caveats, or pitfalls to be aware of? Is there a better branching strategy than what I have already come up with?

Your feedback is highly appreciated!

P.S. This is for a PHP script stored in Git, but the answers should apply to any language or VCS.

Instead of having two code version with a common base you should design your application in a way to make those premium features plug-able and driven by configuration rather than different code bases.

If you are afraid to ship those premium features (disabled by configuration) with the basic version you can still remove that code in a final build/packaging step and just have two build profiles.

Having this design you can also ship 5 different flavors and get very flexible, maybe even allowing third parties to contribute.
