While most current answers are in favour of conditional compilation instead of branches, there is one scenario where there is a clear benefit to using branches: if you (now or later) decide to make the source code of the basic version available, including all the version history but excluding all the premium features, then you can do so with the branches approach but not with a single branch and conditional compilation.

I'd advise against cherry picking, and instead merge all changes from the basic version into the premium version. There should be no feature or bug fix included in the basic but missing in the premium version. To make things as painless as possible, you should make sure that the premium branch modifies the common files as little as possible. So the premium branch should mostly contain additional files, and perhaps some slight modifications to build instructions. That way, changes from the basic version will merge automatically without causing conflicts.

Greg's answer suggested that you “consider branches for things that will be (or might be) merged back together again later”. With the approach I just described this is the case, except that the final branch for all commits will be master-premium not master (which is actually master-basic).

Sub-modules would of course be an option as well. It depends on your build process, but if you can make the premium version into a project which uses the basic version as a module, that would be just fine. You might however have a harder time if at some point you decide to cherry-pick features from the premium branch into the basic branch. With sub-modules such a change would be represented as two distinct commits, whereas with branches this would be a single commit to the basic version, and the next merge into the premium version would know that these changes are already included and don't have to be merged again.

While most current answers are in favour of conditional compilation instead of branches, there is one scenario where there is a clear benefit to using branches: if you (now or later) decide to make the source code of the basic version available, including all the version history but excluding all the premium features, then you can do so with the branches approach but not with a single branch and conditional compilation.

I'd advise against cherry picking, and instead merge all changes from the basic version into the premium version. There should be no feature or bug fix included in the basic but missing in the premium version. To make things as painless as possible, you should make sure that the premium branch modifies the common files as little as possible. So the premium branch should mostly contain additional files, and perhaps some slight modifications to build instructions. That way, changes from the basic version will merge automatically without causing conflicts.

Greg's answer suggested that you “consider branches for things that will be (or might be) merged back together again later”. With the approach I just described this is the case, except that the final branch for all commits will be master-premium not master (which is actually master-basic).

Sub-modules would of course be an option as well. It depends on your build process, but if you can make the premium version into a project which uses the basic version as a module, that would be just fine. You might however have a harder time if at some point you decide to cherry-pick features from the premium branch into the basic branch. With sub-modules such a change would be represented as two distinct commits, whereas with branches this would be a single commit to the basic version, and the next merge into the premium version would know that these changes are already included and don't have to be merged again.