你头像中的字不可读啊

这种是什么情况下用啊？解决什么问题？

每个公司情况不一样。 这个是适合他们公司的，未必适合其他公司。

看图感觉其它分支只是用于迭代开发的，通过测试的才能合并到主干，楼主的公司是基于主干发布版本了。

从图来看，他们是主干发布

如果是 针对 需求经常变的开发， 应用什么样的分支策略，如：一周可能发好几个版本

这图使用什么工具画的？

OmniGraffle

小需求直接在主干做，长线需求走分支.

是的，而且要求合并到主干，必须尽快上线，否则后面就会排队...

多个人开发一个项目 :)

[i=s] 本帖最后由 nearness 于 2015-1-22 14:45 编辑

每月规划一次功能集，每周迭代发布上线的分支情况简介： 1 master 分支，用于将发布上线内容基线。 2 DEV 分支，即开发主干，每个月从 master 拉出，功能提交至 DEV，发布时拉出 release 分支。 发布完成后将 release 分支合并到 master，并打上 tag。 3 release 分支，用于发布及其发布过程中 bug 修复。

你这里的 release 也只是一种临时性的 dev 分支，并不是 release

你这里的 master 并不是发布的主分支，只是个大杂烩。 这里的 dev 更像是发布分支，因为只要 dev 足够的稳定，就可以直接发布。

你这里的问题是 1）dev 虽然从 master 拉出来却不直接合并回去 2）dev 和 release 并没有直接的关系，却分支之间进行了合并

master 和 release 的的理解是对的，master 是发布基线分支，release 是临时的开发分支，用于发布过程 bug 修复。

DEV 是开发主干，上图中少画了一条线，release 有条往 DEV 合并的线。