首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
coagent
V2EX  ›  程序员

Git 分支管理与版本发布的冲突问题

  •  
  •   coagent · 2013-05-02 17:44:20 +08:00 · 3228 次点击
    这是一个创建于 2454 天前的主题,其中的信息可能已经有所发展或是发生改变。
    在用 Git 做版本控制的童鞋,可以聊聊你们如何管理 Git 分支吗?

    一个持续开发的项目(APP、网站、软件都可),发布第一个版本后,我们面临着要相对固定周期迭代一个版本并对外发布,同时进行新功能开发和现有功能 Bug 的修复。

    你们当计划要发布一个新版本时,是不是会建一个版本分支,然后这个版本发布的所有内容都是在这个分支里处理?

    建这个版本分支前,假定所有新功能开发和 Bug 修复都是在一个开发分支(暂且叫 dev 吧)上往前走,这时如果有三个新功能在开发中、10 个 Bug 在修复中,但计划发布的版本只发布其中 2 个新功能、8 个 Bug 修复,那不是行不通吗?这个版本分支无法创建啊。

    假定不用版本分支,而是每个新功能在开发时,创建一个功能分支,对于 Bug 修复也是如此。当计划下个版本要发布哪些功能时,将所在该版本要发布的功能的功能分支合并到开发主线,删除这些新功能分支,然后创建版本分支,然后直到发布,这个版本的事儿全部在这个版本分支里进行。
    第 1 条附言  ·  2013-05-03 12:41:34 +08:00
    谢谢各位的回复,上午我们内部又讨论一番。得到的结果是:新功能和大的 Bug 都建临时性的分支,所有服务器端的分支管理由一个人严控,开发人员不能推送本地的分支到服务器上去。小的 Bug 或者极小的新功能直接在 dev 开发主线上处理。

    准备发布一个版本时,创建以版本号为名的版本分支,确定了版本号后将相关的功能分支、Bug 分支合并,删除合并进来的临时性分支,这样可以减少同时在上面的分支数量。

    版本发布后,版本分支并入 dev,dev 并到 master,并给 master tag 一个版本号。这时内部的版本分支则可以删除了。

    我们准备试试这样的,看看效果。
    11 回复  |  直到 1970-01-01 08:00:00 +08:00
    wwwjfy
        1
    wwwjfy   2013-05-02 17:56:39 +08:00   ♥ 1
    最后一段大致差不多。

    除了一些神奇的需求,做完一个功能或 bug 都应该放到 master 里吧。某个版本直接打 tag 就行了,没什么只单独属于某个版本的提交
    davepkxxx
        2
    davepkxxx   2013-05-02 18:06:06 +08:00   ♥ 1
    Git在企业项目中的运作。
    每个人都会从主项目中fork一个分支,开发完一个功能或者修复了一个bug就请求合并。
    master是项目技术负责人专属,他会负责定期合并分支。
    当然这个过程中少不了相互交流,建议用邮件形式。
    goinaction
        3
    goinaction   2013-05-02 18:15:38 +08:00   ♥ 1
    参考Gitlab的分支管理嘛,master分支始终保持稳定可发布,dev是开发主线,功能和bug修复再开其他分支,由项目管理人来细致的控制分支merge
    i0xbean
        4
    i0xbean   2013-05-02 19:06:50 +08:00   ♥ 1
    git-flow
    clino
        5
    clino   2013-05-02 19:33:59 +08:00   ♥ 1
    "但计划发布的版本只发布其中 2 个新功能、8 个 Bug 修复,那不是行不通吗?这个版本分支无法创建啊。"
    可以在stable分支上cherry-pick dev分支上的patch
    rrrrutdk
        6
    rrrrutdk   2013-05-02 20:07:33 +08:00   ♥ 1
    jerommix
        7
    jerommix   2013-05-02 22:23:13 +08:00 via Android   ♥ 1
    gerrit.
    coagent
        8
    coagent   2013-05-03 06:37:23 +08:00
    @davepkxxx 这样的流程,这里的“开发完”是不是指程序员写好代码并自己做了些测试,认为没问题了就请求合并么?中间是没有其他测试人员的。
    coagent
        9
    coagent   2013-05-03 06:49:53 +08:00
    @goinaction 我也觉得这样比较好,但内部不少人觉得每个功能和 bug 修复都创建一个分支会造成很多分支,后面要合并这些分支还会有很多冲突,觉得太复杂了。
    vietor
        10
    vietor   2013-05-03 09:18:14 +08:00
    "后面要合并这些分支还会有很多冲突,觉得太复杂了",的确给人这样的感觉,只能逐步说服这部分人,这样的复杂带来的好处更多些。此外,新功能的增加和BUG修复不应该对原始结构进行大的改动,冲突没有想象的那么多。在实际开发过程中,我们的团队始终强调一句话“别对代码进行整体格式化”,就是避免因为类似“整体格式化”而产生的不必要却“很麻烦”的冲突。
    davepkxxx
        11
    davepkxxx   2013-05-03 09:46:53 +08:00
    @coagent 是这个意思,测试不应该影响正常开发工作。项目开发到一定阶段就应该建立一个里程碑,然后让测试小组进行测试。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2912 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 24ms · UTC 05:04 · PVG 13:04 · LAX 21:04 · JFK 00:04
    ♥ Do have faith in what you're doing.