版本管理 中午画的分支版本管理示例图

mailtoeiya@yahoo.com.cn · 2013年03月28日 · 6 次阅读

[i=s] 本帖最后由 eiya 于 2013-3-28 13:55 编辑

部分情况下适用 :) [attach] 2107[/attach]

你头像中的字不可读啊

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

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

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

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

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

这图使用什么工具画的?

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

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

多个人开发一个项目 :)

[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 合并的线。

需要 登录 后方可回复。