对Git Flow 开发模型的理解

96
KentonYu
2016.03.05 10:18* 字数 1132

支持原创,原文地址:www.KentonYu.com

又是一段时间没写博客了。。一直生活在甲方的世界里。。。可能也是自己懒癌复发了吧。。
最近一个项目,因为需求上比较容易(开发时间比较充裕),所以尝试了通过Git Flow来管理项目源代码,从而探索下是否可以提高整体开发效率。在这之前,公司用的只是dev + master,几个开发同时在dev上开发,时不时就会有冲突,特别是项目中的xib文件较多时,很容易发生xib冲突(头疼。。。当然只要在commit之前看下文件变更记录,把不需要的变更放弃掉,但是难免会有疏忽的时候)。

  • Git Flow 介绍

Git Flow是构建在Git之上的一个组织软件开发活动的模型,是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。


Git Flow 全貌

其实学习Git Flow,主要还是理解几个分支的用处,在使用时通过严格的分割,将冲突概率降到最低,提高开发效率。下面我就按自己的理解来描述下主要的几种分支。

master

这个分支上只存在上线版本,每个commit都应该对应一个版本号。

仅在发布新的可供部署的代码时才更新master分支上的代码

develop

dev分支简单来说就是开发分支,它保存着开发过程中的最新版本。也就是说每当完成一个需求(feature)就应该合并到dev分支上。

feature

feature:功能。这个分支显而易见,是用来存每一个新功能(需求)的。每一个功能模块(较复杂的最好拆分下)可以做为一个feature。一般情况,每一轮迭代结束后的feature分支都应被合到dev分支上。这类分支也可以是做为实验性分支,比如在上面尝试一些开发,如果达不到预期效果也可以放弃该分支。

release

release分支可以看做是存储上线版本之前的分支。用一个实际情况来描述下,第二轮sprint结束,需要上线一个版本(还未进行测试和fix bugs),这时候第三轮sprint又要开始了。根据之前master的原则,是只存在上线版本的,因此我们可以用release分支,存一个待上线版本,然后dev就可以进行sprint3迭代了。这时候sprint2的bug 就可以在release上修复,当测试通过之后,就可以将release合进master上,同时dev需要merge下release分支。

hotfix

hotfix:热补丁。它的作用是线上版本出现bug时,可以通过hotfix来fix,然后产生一个新的发布版本,合并到master上,同时dev需要merge hotfix。这样的好处是可以打断dev上正在开发的进度。

以上就是Git Flow模型的大致概念。在实际开发过程中,这个模型并不是一成不变的,根据每个开发团队或每个项目可以进行一定的变化。

  • Git Flow 实际使用
    日常开发中,使用SourceTree来操作Git居多。SourceTree中自带Git 工作流模型,简单的使用只需要点击应用即可。


    SourceTree 自带工作流
SourceTree 自带工作流

当然这边也可以进行自定义,或者说不使用这个模型,自己通过新建分支来实现Git Flow。
我实际运用中,大致是这样的:


利用group
  • 心得
    1.dev有更新时,feature分支及时rebase(变基,衍合),不然当合并该feature时可能会出现很多冲突(Q_A_Q)。
    2.可以复用页面的一些功能模块应该分配给同一个开发去做,不然在页面复用上会有问题。因为每个feature是分割开的。

  • 引用
    1.基于git的源代码管理模型——git flow http://www.ituring.com.cn/article/56870

日记本