美文网首页持续集成笔戈 Web Team计算机
企业级开发:Gitflow Workflow工作流

企业级开发:Gitflow Workflow工作流

作者: 流星狂飙 | 来源:发表于2015-07-24 15:49 被阅读18415次

    我说的以下流程,sourceTree等工具已经完美的支持了,鼠标点两下就完成了。简直是完美。

    简介

    Feature Branch Workflow是一种非常灵活的开发方式。对于一些规模比较大的团队,最好就是给特定的分支赋予不同的角色。除了功能分支(feature branch),Gitflow Workflow还使用独立的分支来准备发布(preparing)维护(maintaining), 和记录版本(recording releases)

    分支类型和流程

    下图能说明整个流程,只要你看得懂的话。该模式来自 Nvie

    主分支

    主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和development分支。

    master 分支

    master分支上存放的应该是随时可供在生产环境中部署的代码(Production Ready state)。当开发活动告一段落,产生了一份新的可供部署的代码时,master分支上的代码会被更新。同时,每一次更新,最好添加对应的版本号标签(TAG)。

    develop分支

    develop分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码(Nightly build)。因此这个分支有时也可以被称作整合分支(integration branch)。

    辅助分支

    辅助分支

    辅助分支是用于组织解决特定问题的各种软件开发活动的分支。辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。这些分支与主分支不同,通常只会在有限的时间范围内存在。

    辅助分支包括:

    1. 用于开发新功能时所使用的feature分支;
    2. 用于辅助版本发布的release分支;
    3. 用于修正生产代码中的缺陷的hotfix分支。

    以上这些分支都有固定的使用目的和分支操作限制。从单纯技术的角度说,这些分支与Git其他分支并没有什么区别,但通过命名,我们定义了使用这些分支的方法。

    feature 分支

    使用规范:

    1. 可以从develop分支发起feature分支
    2. 代码必须合并回develop分支
    3. feature分支的命名可以使用除masterdeveloprelease-*hotfix-*之外的任何名称

    feature分支(有时也可以被叫做“topic分支”)通常是在开发一项新的软件功能的时候使用,这个分支上的代码变更最终合并回develop分支或者干脆被抛弃掉(例如实验性且效果不好的代码变更)。

    release分支(preparing)

    release分支

    使用规范:

    • 可以从develop分支派生
    • 必须合并回develop分支和master分支
    • 分支命名惯例:release-*

    release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息(版本号、发布时间、编译时间等等)。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交,进入新的软件开发迭代周期。

    当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能,并且已通过所有测试时,我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内(避免由此引入一些不可控的系统缺陷)。

    成功的派生了release分支,并被赋予版本号之后,develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。版本号的命名可以依据项目定义的版本号命名规则进行。

    hotfix分支(maintaining)

    使用规范:

    • 可以从master分支派生
    • 必须合并回master分支和develop分支
    • 分支命名惯例:hotfix-*

    除了是计划外创建的以外,hotfix分支与release分支十分相似:都可以产生一个新的可供在生产环境部署的软件版本。

    当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候,就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。

    这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作,能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。

    问题

    管理冲突

    1. 多个Feature 分支开发完成,提交到develop 分支时,修改了共同的模块。
    2. release 分支或者hotfix 分支修改了bug合并回develop时,发现develop分支已经往前面走了一截。

    在执行可能有冲突的操作前,先查看一下 暂存区 和 工作目录,保证其中没有修改。

    比如使用git stash就可以把暂存区 和 工作目录的修改保存起来,让暂存区 和 工作目录处于干净的状态。

    更进一步

    Gitflow workflow 和pull request 组合起来使用,代码审查机制的加入,会让这个模式大放异彩。下一篇文章中, 我会详细介绍 代码审查😘😘😘😘。

    扩展:Forking Workflow

    Forking Workflow与以上讨论的工作流很不同,一个很重要的区别就是它不只是多个开发共享一个远程仓库(central repository),而是每个开发者都拥有一个独立的服务端仓库。也就是说每个contributor都有两个仓库:本地私有的仓库和远程共享的仓库。

    Forking Workflow

    Forking Workflow

    Forking Workflow这种工作流主要好处就是每个开发者都拥有自己的远程仓库,可以将提交的commits推送到自己的远程仓库,但只有工程维护者才有权限push提交的commits到官方的仓库,其他开发者在没有授权的情况下不能push。Github很多开源项目都是采用Forking Workflow工作流。

    文章来源

    Git版本控制与工作流

    基于git的源代码管理模型——git flow

    相关文章

      网友评论

      • 小胡闹:有个疑问,当publish一个feature之后,小伙伴track了这个feature,并且向远程仓库提交了行代码,这时我要更新直接git pull吗?当使用git flow feature pull xxx时,提示已经过时,使用git flow feature track xxx提示feature已经存在,track命令好像只用于获取一个远程仓库的feature
      • zhuhf:几个问题:
        1、feature 分支差不多就可以合并到 develop,这个差不多指的应该不是测试通过吧?
        2、develop 准备 release 分支的时机是什么?通常情况才,公司要经过 测试、预发等环境的验证后,才会打正式包。那么,测试、预发的版本测试,在哪个分支进行?
        371fd16bab38:1、QA依据feature分支测试,测试通过,切回develop分支,合并feature分支上的修改
        2、develop分支合并feature分支上的修改之后,拉去远程master分支上的代码,然后就可以检出release分支了
      • 新地球说着一口陌生腔调:也是可进行每日夜间发布的代码 这个是什么意思呢?
      • Karos_凯:有一点我没有明白,就是develop分支测试通过后,就会拉出release分支,release分支没上又要合并到master,后面的fix都是基于master的,那release貌似没什么意义啊
        mqlsq:release分支的作用应该代码冻结,非重大bug就不进行修复.个人理解是这样子的.
        Karos_凯:@流星狂飙 好的,现在明白了,谢谢了
        流星狂飙:release 是发布分支,即将发布的下一个版本。与此同时,你们还有一些功能正在开发,但是是属于下下一个版本的,这些不需要发布的功能代码只能并入 develop分支。

        fix 纯粹用于修复线上的 bug
      • sevenlx:您好 求一下Nvie的那个图的画图工具知道么 找的好辛苦啊
        人世间:keynote
      • 敢死队111:看的有点小晕 不知道这种工作流是针对本地库的还是远程库的?
        还是说本地库的分支和远程库的分支是一样的保持对应的关系?
        371fd16bab38:我理解,这里的所有分支(feature、release、master、develop、hotfix),都是指本地的分支,
      • zhuhf:文章写得非常好,看了之后觉得有一个问题,希望博主解答下,比如说:
        从develop上开一个feature分支,比如用来开发新的功能,此时在feature开发过程中发现develop上的代码有bug,看了那张图的意思是在develop修改这个bug。如果这个bug影响到了feature的功能,我需要从develop上merge到feature吗,或者有更好的办法?
        zhuhf:@流星狂飙 明白,谢谢!
        流星狂飙:@hiphonezhu @云朵妹妹 在开发功能分支的时候,应该实时同步develop分支。 如果在你功能分支开发,你每天到公司开始开发的第一件事就是从 develop 获取到最近代码,然后合并到你的feature 分支。

        保证本地分支和develop 分支同步
        d12a02e9599a:@hiphonezhu 我也有相同的问题,不过我是这么想的,如果有你所说的这种情况,git会产生冲突,并且提示你手动修复冲突,这种情况下,你把远端的develop分支fetch,再在和基础上从新编写你的feather。目前这是我的想法
      • 编程小翁:讲得非常好,点赞
      • chrisxlq:移动端app居然没得打赏
      • hainuo:不错的模式,对于辅助分支讲解得非常详细

      本文标题:企业级开发:Gitflow Workflow工作流

      本文链接:https://www.haomeiwen.com/subject/awqmqttx.html