git best strategy for two version development

[Carlos Pereira <jose.carlos.pereira@ist.utl.pt>]

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/