又是一段时间没写博客了。。一直生活在甲方的世界里。。。可能也是自己懒癌复发了吧。。
ps:图片无法显示请点击：“传送门”
最近一个项目，因为需求上比较容易（开发时间比较充裕），所以尝试了通过Git Flow来管理项目源代码，从而探索下是否可以提高整体开发效率。在这之前，公司用的只是dev + master，几个开发同时在dev上开发，时不时就会有冲突，特别是项目中的xib文件较多时，很容易发生xib冲突（头疼。。。当然只要在commit之前看下文件变更记录，把不需要的变更放弃掉，但是难免会有疏忽的时候）。
Git Flow 介绍
Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。
其实学习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 工作流模型，简单的使用只需要点击应用即可。
当然这边也可以进行自定义，或者说不使用这个模型，自己通过新建分支来实现Git Flow。
我实际运用中，大致是这样的：
心得
1.dev有更新时，feature分支及时rebase（变基，衍合），不然当合并该feature时可能会出现很多冲突（Q_A_Q）。
2.可以复用页面的一些功能模块应该分配给同一个开发去做，不然在页面复用上会有问题。因为每个feature是分割开的。
引用
1.基于git的源代码管理模型——git flow http://www.ituring.com.cn/article/56870