Re: git best strategy for two version development

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]