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.