怎么通过git维护两个主体代码很接近的两套程序?

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Pro Git

› Atlassian Git Tutorial

› Pro Git 简体中文翻译

› GitX

这是一个创建于 4120 天前的主题，其中的信息可能已经有所发展或是发生改变。

朋友用.net的,他们有一个奇怪的工具可以实现这种功能:

他们有两个产品,一个是企业版,一个是免费版,然后他们有两个项目组A和B. A负责做企业版, B负责做免费版.

企业版和免费版的功能可以说: 企业版是免费版的父集, 免费版是企业版的子集.企业版和免费版的界面完全不同(我听他介绍的意思是一套UI,一些细节的地方不同,比如名称,提示信息等等)

开发的时候,大部分情况下是企业版持续开发, 免费版通过Merge的方式,整合企业版代码库,然后持续开发,个别的情况下也会由企业版去Merge免费版的代码库.

他们用的微软的一个版本管理工具(不是VSS),名字我忘了.先不讨论这个,如果使用git,用什么办法能够实现这种需求?

免费版

企业

git

19 条回复 • 1970-01-01 08:00:00 +08:00

lichao

2013-08-12 18:04:03 +08:00

git branch

vietor

2013-08-12 18:05:37 +08:00

颠倒了，如果免费版作为主库，企业版作为子库就非常简单了。
当然，如果独立出一个新的主库，而免费版与企业版都作为子库也是行的。

git都是整分支merge的，所以可能需要改变原来的主、子模式。

saharabear

2013-08-12 18:16:49 +08:00

@vietor 有一个地方是我不太明白的,还请教一下.比如:

企业版作为子库,免费版作为主库,那么打一个比方,免费版在ui_module中设置了一个UI上的元素为a.jpg,企业版merge了免费版后,在ui_module中设置的是b.jpg,这样如果ui_module不再变,那自然一切都好办.如果免费版又再次修改了ui_module中的其他设置,这样针对企业版再merge的时候,就需要手工去处理a.jpg到b.jpg的冲突问题. 这样就需要在设计过程中尽量通过文件分解,方法的分解来避免这种merge,git下面应该这么处理,我理解得没错吧?

我去打听一下我朋友那边的方式是如何处理这种潜在的大量可能出现冲突的问题的.

另外,独立出一个主库,免费版和企业版都分别做子库似乎是一个好主意,我再想想.

lqs

2013-08-12 18:17:32 +08:00

项目使用两套编译参数，代码里根据参数来判断显示不同的名称/提示信息。

saharabear

2013-08-12 18:21:22 +08:00

@lqs 这样应该会产生很复杂的编译工具的配置文件,就是说不使用版本管理来解决这个问题,而是同一个代码库,使用不同的编译配置文件来处理两套产品?这样似乎不可行,因为我考虑了一下,还有个问题是免费版和收费版还是有子集关系的,肯定需要修改一些代码,接口之类的.

qinxg

2013-08-12 18:23:57 +08:00

LZ说的是微软的tfs

saharabear

2013-08-12 18:25:53 +08:00

@qinxg 我不知道是不是tfs,反正觉得挺神奇的,听我哥们说他们用这套工具解决这种需求是很容易的,而他说这套工具秒杀git/subversion.

lqs

2013-08-12 18:42:25 +08:00

@saharabear 配置里就一项： [是否为企业版] ，代码里判断 if (企业版) { 增加企业版的功能菜单 }

但要是免费版和企业版的功能差别分散的太广，就不太方便了。

qq286735628

2013-08-12 19:01:49 +08:00

我是这样做的
一开始只有一个master的branch，我从这拉三个分支出来，一个dev，一个enterprise，一个free
然后分别切换到enterprise和free分支上面，写差异化的代码，并各自commit

后续维护开发的时候，只在dev分支上面进行，每完成一个功能后，merge到enterprise分支（如果free分支也要支持这个特性，那么就也merge一份到free分支）

潜在问题：
这种模式，在merge的时候，一定要看清楚是谁merge谁，不然的话，差异化的部分代码会被覆盖掉。
当然，在给enterprise和free分支提交差异化代码的时候，可以创建一个patch，当不小心差异化代码被覆盖后，可以通过patch来快速恢复

saharabear

2013-08-12 19:02:02 +08:00

@lqs 在代码里这样写肯定是属于业务上写死了,不够灵活.如果功能差别小,这样做就没问题,一分散就不太方便了.

saharabear

2013-08-12 19:33:16 +08:00

我做了一个小尝试,现在用git做了三个库,一个库是base库,在里面有三个分支, 一个是dev分支,一个master分支,一个patch分支.

然后分别做了一个prod库和一个free库,这两个库中都建上dev, master和一个专门的patch分支

这样prod和free都不直接相互merge,都通过base来做,保持base中是完整代码库,然后merge的过程用专门的分支patch来处理,然后再将merge后的代码从patch中再向dev中merge,再从dev跑过单元测试后向master中处理.

试验是成功了,可是觉得这样太复杂了,并且需要专人处理merge工作?应该还是复杂了一点,容易出错.

@qq286735628

@vietor

vietor

2013-08-12 20:50:55 +08:00

过程复杂点，可靠度才有保障，开发人员多的情况下更是如此。

向Base进行merge的时候需要只是需要小心一点，是否需要专人处理看你们Team对Git的熟练度。