Re: git best strategy for two version development

> On Sat, Feb 08, 2014 at 02:06:41AM +0000, Carlos Pereira wrote:
>    
>> 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?
>>      
> That's pretty much the way to do it.  If you check in master-A, then
> create the master-B branch off of that, copying in the code from B and
> checking it in, then when you merge from master-A to master-B, git will
> basically do the right thing.  Changes you make on master-A that are
> specific to that version will probably conflict, but they should be easy
> to fix up.
>    

> I basically do this for a consulting project for a client: there's
> generic code in master, and a special branch for the client.  Since most
> changes don't touch the modified code, conflicts are infrequent, and I
> can fix them up when they occur.  I also do it for my dotfiles, which
> vary slightly between home and work.
>
> You could also make the changes to master-B as a set of commits on top
> of master-A, and always rebase master-B on master-A, but this isn't a
> good solution if other people are going to be using your code.  It has
> the benefits of keeping the history free of frequent merges, which may
> or may not be important to you; it doesn't really bother me very much.
>
>