git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
saharabear
V2EX  ›  git

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

  •  
  •   saharabear · Aug 12, 2013 · 5091 views
    This topic created in 4661 days ago, the information mentioned may be changed or developed.
    朋友用.net的,他们有一个奇怪的工具可以实现这种功能:

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

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

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

    他们用的微软的一个版本管理工具(不是VSS),名字我忘了.先不讨论这个,如果使用git,用什么办法能够实现这种需求?
    19 replies    1970-01-01 08:00:00 +08:00
    lichao
        1
    lichao  
       Aug 12, 2013
    git branch
    vietor
        2
    vietor  
       Aug 12, 2013
    颠倒了,如果免费版作为主库,企业版作为子库就非常简单了。
    当然,如果独立出一个新的主库,而免费版与企业版都作为子库也是行的。

    git都是整分支merge的,所以可能需要改变原来的主、子模式。
    saharabear
        3
    saharabear  
    OP
       Aug 12, 2013
    @vietor 有一个地方是我不太明白的,还请教一下.比如:

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

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

    另外,独立出一个主库,免费版和企业版都分别做子库似乎是一个好主意,我再想想.
    lqs
        4
    lqs  
       Aug 12, 2013
    项目使用两套编译参数,代码里根据参数来判断显示不同的名称/提示信息。
    saharabear
        5
    saharabear  
    OP
       Aug 12, 2013
    @lqs 这样应该会产生很复杂的编译工具的配置文件,就是说不使用版本管理来解决这个问题,而是同一个代码库,使用不同的编译配置文件来处理两套产品?这样似乎不可行,因为我考虑了一下,还有个问题是免费版和收费版还是有子集关系的,肯定需要修改一些代码,接口之类的.
    qinxg
        6
    qinxg  
       Aug 12, 2013
    LZ说的是微软的tfs
    saharabear
        7
    saharabear  
    OP
       Aug 12, 2013
    @qinxg 我不知道是不是tfs,反正觉得挺神奇的,听我哥们说他们用这套工具解决这种需求是很容易的,而他说这套工具秒杀git/subversion.
    lqs
        8
    lqs  
       Aug 12, 2013
    @saharabear 配置里就一项: [是否为企业版] ,代码里判断 if (企业版) { 增加企业版的功能菜单 }

    但要是免费版和企业版的功能差别分散的太广,就不太方便了。
    qq286735628
        9
    qq286735628  
       Aug 12, 2013
    我是这样做的
    一开始只有一个master的branch,我从这拉三个分支出来,一个dev,一个enterprise,一个free
    然后分别切换到enterprise和free分支上面,写差异化的代码,并各自commit

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

    潜在问题:
    这种模式,在merge的时候,一定要看清楚是谁merge谁,不然的话,差异化的部分代码会被覆盖掉。
    当然,在给enterprise和free分支提交差异化代码的时候,可以创建一个patch,当不小心差异化代码被覆盖后,可以通过patch来快速恢复
    saharabear
        10
    saharabear  
    OP
       Aug 12, 2013
    @lqs 在代码里这样写肯定是属于业务上写死了,不够灵活.如果功能差别小,这样做就没问题,一分散就不太方便了.
    saharabear
        11
    saharabear  
    OP
       Aug 12, 2013
    我做了一个小尝试,现在用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
        12
    vietor  
       Aug 12, 2013
    过程复杂点,可靠度才有保障,开发人员多的情况下更是如此。

    向Base进行merge的时候需要只是需要小心一点,是否需要专人处理看你们Team对Git的熟练度。
    refresh
        13
    refresh  
       Aug 12, 2013
    我觉得同一套代码不同的编译参数好一些吧,比如说Xcode不同的target
    msg7086
        14
    msg7086  
       Aug 13, 2013
    没人用rebase?
    fire9
        15
    fire9  
       Aug 18, 2013
    Ricepig
        16
    Ricepig  
       Aug 19, 2013
    @saharabear TFS这么强悍啊~~~必然是TFS了,就是SourceSafe的全方位升级版
    saharabear
        17
    saharabear  
    OP
       Aug 19, 2013
    @Ricepig 搜索了一下TFS,果然强大。
    hhrmatata
        18
    hhrmatata  
       Aug 19, 2013 via Android
    可以查询下开源软件,如ubuntu等是如何维护不同发行版
    standin000
        19
    standin000  
       Aug 19, 2013
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   896 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 51ms · UTC 22:32 · PVG 06:32 · LAX 15:32 · JFK 18:32
    ♥ Do have faith in what you're doing.