Re: git best strategy for two version development

On 02/08/2014 03:56 AM, brian m. carlson wrote:

On Sat, Feb 08, 2014 at 02:06:41AM +0000, Carlos Pereira wrote:
   

quoted

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.
   

You are right! git does not try to merge everything, only changes 
commited on the other branch (branch-A), after creating branch-B... 
otherwise it would be reverting the work done on the current branch, 
which does not make much sense...

Thank you very much...
C

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.