git best strategy for two version development

Hello,

I am a git and CVS newbie, I bought and red most of the excellent Pro Git book by Scott Chacon, but I still have a doubt. I have a package that I distribute in two versions differing only in one library: version_A uses this library, version_B uses my own code to replace it. For strategic reasons I want to keep it this way for the time being. Both versions have the same documentation, the same data files, and 99% of the source code is the same (a few makefile changes, two additional files in version_B and some minor changes: a diff -r has only 170 lines). The question is what is the best strategy to manage a situation like this with git?

Shall I maintain two different repositories? I don't think so...

Apparently the best solution would be to maintain two long term branches, say mater_A and master_B, and merge all later developments in both branches, keeping the initial difference... Specifically:

1) do some new work in branch master_A, commit, etc.
2) checkout master_B and merge the new work in master_B, without merging 
the initial diff between the two versions.

What is the better way to do that?

I suppose this is a fairly common situation, for example, some standalone code distributed with two different GUI toolkits. I could carefully choose which commits should be merged in both branches (the changes in standalone code) and which should not (the changes in GUI code), but that is error-prone and seems to miss the whole point of using a managment system...

How shall I handle this? Thanks for your help!

Regards, Carlos Pereira, http://www.gamgi.org/