写得真好，逻辑慎密，分析合理

很细心。 印象中以前有遇过类似问题，一般都是直接上级目录加个只读权限就糊弄过去了。没想到还有这讲究。

[i=s] 本帖最后由 cleetion 于 2014-6-13 13:45 编辑

嗯， 官网的解释是一个很好的应用实践。

除此我自己实践遇到的好处是，通过 scheme，区分两种管理员角色的分工。 jira system administrator 定义系统存在哪些 issue type scheme，project administrator 选择自己项目适用的 issue type scheme。

问题结束，谢谢答疑。

PS：[b]@ 知名不具呀 [/b] 是几个意思？

看来是我没说清楚。 我的意思其实就是完全抛弃 scheme 这个概念。

比如我可以在系统里预先定义好所有的 issue type，然后新建/编辑项目的时候，可以直接从所有的 issue type 中挑选所需的添加到项目里来，也可以直接把不需要用到的 issue type 移除。

其实现在用 scheme 这个东东，也可以实现自己的需求，我只是不太理解 jira 中为啥要加这么个概念，而且是个基础概念，系统中处处可见。

开始 -> 所有程序 -> TortoiseSVN -> TortoiseMerge -> view -> settings

这个跟以前的一个帖子发的应该是同一个教程， [url]http://bbs.scmroad.com/forum.php?mod=viewthread&tid=205&fromuid=25357/url][

没有必然联系。但谁知道呢，这操蛋的世道。

嗯，所以说靠谱的分析来源于靠谱的数据。

不管怎么说，辛苦。

去年也参加了投票， 一年下来，略微小涨，但是涨幅实在不好意思见人。

蓝色粗大字体， 是问题提出者觉得适合眼前实际情况的最优选择。

杭州-andy： 那需求 1 做完，合并到主干的时候，顺便也合并到还在开发的分支 你们的产品没版本计划么 一直一直在开发 就不计划下哪个需求放到什么版本 给主干订一个版本，上面需要完成什么需求提早定下来 就不会说老是要拉出分支了吧。。 我们以前也是这么干 我们之前每个需求都会订在那个版本去实现 不会出现你这种情况

深圳-cleetion ： 嗯， 硬要说起来， 也可以说是有版本规划的， 但是， 两个版本时间相隔很短的， 一个星期的有， 三五天的有， 1 天的也有 你说的产品版本规划， 应该是版本发布时间相隔比较长的吧，

杭州-andy： 你们的产品规划就有问题 靠你一个人估计很难搞定。。 怎么会一天就出一个版本

深圳 - 莲： 不过你可以推动解决这个问题。

深圳-cleetion: 是有问题， 但是互联网公司大部分就是这样的

杭州-andy: 靠 SCM 去推动解决真的好困难啊

北京 - 恐龙: 互联网公司大部分就是这样的 这是借口

深圳-Eiya: 说明这是业务需要.

北京 - 恐龙: 窝窝团也这么说的 我当时就说是放屁

杭州-andy: 有什么特殊性么？

深圳-Eiya: 这个问题上我支持窝窝团.

北京 - 恐龙: 窝窝团产品经理根本就不懂排列需求的优先级 研发经理根本就不去合并需求，而且开发模式是个人分支模式 我曾经在的第一个项目组，就因为分支规划混乱，出了好几次事故

深圳-cleetion: 恐龙， 照你这个角度说下去， 最后的解决办法无非是我走人了。。 因为我无法去解决产品经理不懂排列需求这个问题，如果你有办法， 赐教吧

杭州-andy: 你增加点工作量 有 1234 分支的话，1 合并到主干，也同步合并到 234 分支

北京 - 恐龙: 直到我们配管把分支策略订下来，强制要求研发经理把需求规划到分支，并且把需求可以合并的就合并开发

深圳-cleetion : 1、跟新浪微博合作 2 月 1 号上线 2、本站要做一个用户抽奖活动 2.4 上线 3、会员管理 要改版 4.15（预定，可能延后） 4、优化后台管理功能 3 月初上线（上线时间不是很严格，做好了就上）

就像我这里举的场景， 或者基于合作方， 或者基于市场策略， 上线时间是无法改变的，不单是我无法改变， 产品、项目 也无法改变

北京 - 恐龙: 这样下来，第一个项目质量才慢慢的稳定

上海 - 虹霖： 互联网，一般就分支。主干

北京 - 恐龙: 并不是说强制更改上线时间，是把可以合并的需求合并在一起坐 比如你的第一个需求 2.1 要发布，那么可以顺手修改小 bug

上海 - 虹霖: 主干做 build 分支

杭州-andy: 1 和 2 可以合一起做么

深圳-cleetion: andy， 你这里的同步合并到其它分支， 是指把 1 合并到 234，还是说把 1 合并到主干后，再把主干合并到 234

北京 - 恐龙: 而大的严重的 bug 可以放在 3 需求上

上海 - 虹霖: 一个项目一个分支，不就完了，

杭州-andy： 这个有什么区别人么，你 1234 都是同一个主干拉出来的。。。

北京 - 恐龙： 合并操作，依据主干上有没有其他新的内容，如果没有，那么 1 向主干 +2+3+4 合并

深圳-cleetion： 是从同一个主干拉出来的， 但是不一定是基于主干同一个基准点拉出来的

北京 - 恐龙： 如果主干还有别的新的内容 那么就必须是 1→主干→2\3\4

深圳-cleetion： 恐龙的意思是 最后发布的时候 用分支来打包发布？

上海 - 虹霖： 项目需要建分支的时候才建分支 不要整个分支合并

北京 - 恐龙： 看分支代码起始点

上海 - 虹霖： 只合并修改的文件的版本

北京 - 恐龙： 代码起始点决定了 合并的顺序 1、如果代码起始点相同，那么主要依据分支发布的时间顺序 2、如果代码起始点不同，那么合并时新起点分支的需要向老起点分支合并 这样操作能避免覆盖已经发布的新的功能

深圳-cleetion： 这样还是没走出 分支 合并到 主干， 主干合并到分支 ， 分支最终又合并到主干 的套路

北京 - 恐龙： 而正常的建议，分支要及时合并，尤其当一个分支发布完毕，那么建议及时向存活分支 以及主干 合并代码 “分支要及时合并，尤其当一个分支发布完毕，那么建议及时向存活分支 以及主干 合并代码”

如果这样做，就不需要从主干向分支合并代码

深圳-cleetion： 恐龙 ， 我们发布 基本都是从 主干来发布的， 分支发布也有 但是很少

北京 - 恐龙： 但是 你要知道你们主干还有小 bug 修改 如果没有这个修改，你们是不需要主干向分支合并，这个操作步骤的 这是你们目前存在的一个问题

深圳-cleetion： 你总算说到痛处了

北京 - 恐龙： 能把这些小 bug 也放到分支上做，就简单了一步 互联网公司的分支策略不能处处开花 这样最累的就是配管，tag 标记一旦疏忽，就不知道什么时候发的是那个版本

深圳-cleetion： 呵 这我倒是从来不 tag

广州-airroot： 不打 tag 发版本？

深圳-cleetion： 这个问题我倒不操心， 现在就是被这个分支合并弄得很累

深圳-Eiya： 从来不 tag...

杭州-andy： ！！！！

北京 - 恐龙： 至于分支合并 可以放给研发去做 合并过程中的冲突可以及时的解决 分支向主干合并，要控制在 cm 手中

杭州-andy： 合并让配管做有点坑啊

深圳-cleetion： 我们打包发布的版本是从我这里出的， 我写了脚本来做打包的操作， 脚本里顺便写了个功能， 记录下每次打包时，源代码的 svn 版本信息， 里面就带了版本号， 所以如果打 tag 是为了追溯上线版本的源代码， 那我是不需要额外再去打 tag 的

北京 - 恐龙： tag 不是仅仅的追溯版本 还有一点是更方便的拿到上线版本做系统恢复

深圳-cleetion： 哦， 那你说说其它的用处 我有了版本号， 直接从 svn 把这个 revision 取出来， 不是也可以做系统恢复吗

北京 - 恐龙： 研发人员是懒惰的，是懒于去翻 log 日志的，更懒的去看你的发布记录 你有版本号，直接取。那你请假。。

深圳-cleetion： 算了， 不纠结 tag 的问题， 反正现在我没为这个问题操过心

北京 - 恐龙： 你就想想 和产品经理 还是研发经理共同解决掉主干开发小功能的这个操作， 你剩下的问题就是分支间的合并了

深圳-cleetion： 嗯， 很有价值的建议， 我自己身在局中， 倒是没意识到这个， 一直没理清主要矛盾 虽然说最主要的矛盾还是在于版本规划

北京 - 恐龙： 。。。是主干开发的 分支策略

深圳-cleetion ：

大家貌似对我这种 并行多分支， 主干合并到分支 的做法很有看法，

我直接来举个 具体的场景吧

我们是互联网公司。 假如 当前的需求如下，这几个需求上线的时间不统一，有先有后。 1、跟新浪微博合作 2 月 1 号上线 2、本站要做一个用户抽奖活动 2.4 上线 3、会员管理 要改版 4.15（预定，可能延后） 4、优化后台管理功能 3 月初上线（上线时间不是很严格，做好了就上）

于是从主干上建了 4 个分支出来做开发，同时主干打开提交权限，用于 bug 修复（这类的是需要随时上线的，发现 bug 马上修复简单测试随时上线）； 需求 1 开发完成了， 准备上线，于是分支 1 合并到主干打包到 beta 环境做预上线测试。第一次合并， 冲突基本很少或者没有。beta 测试（如有 bug 立马修复）通过后上线。 需求 2 开发完成了， 准备上线，于是分支 2 合并到主干打包到 beta 环境做预上线测试。第二次合并，看功能的耦合度，冲突或多或少。beta 测试（如有 bug 立马修复）通过后上线。 主干修复 bug …… …… 主干修复 bug 来到 2 月底了，这时需求 3 的分支相对于主干， 已经是个老分支了。需要把主干上的新代码合并到分支 3，便于解决主干和分支的不一致。 主干修复 bug …… …… 主干修复 bug 又来新需求，没办法，新分支给你。开发去吧 需求 4 开发完成了， 准备上线，于是分支 4 合并到主干打包到 beta 环境做预上线测试。这时候，冲突基本较多，运气好就比较少。beta 测试（如有 bug 立马修复）通过后上线。 又来新需求，没办法，新分支给你。开发去吧 来到 3 月底了，这时需求 3 的分支相对于主干， 又是个老分支了（虽然曾经合并过一次）。需要把主干上的新代码合并到分支 3，便于解决主干和分支的不一致。 主干修复 bug …… …… 主干修复 bug 终于，需求 3 开发完成，准备预上线测试。果断合并分支 3 到主干（傻眼了， 分支 3 上已经包含了主干的部分新代码），于是 大量冲突/目录结构冲突 都出来了。 …………

………… 其它需求的分支默默开发中

昆明-sophia ： 最初设计发布的时候，就确定哪几个功能一定上线，在主干上进行开发，不确定上线的功能可以考虑开分支 我试用过

北京 - 恐龙 ： 记住一点，分支策略是根据产品特性来定的 主干开发 分支发布、修改小 bug，这种适合并行需求较少的产品 互联网行业的产品大多适合多分枝并行开发、发布（或主干发布）的分支策略

杭州-andy ： 你要把主干的新代码合并到分支上有点不理解啊。。 都要合并到分支上，我感觉都可以不用拉分支

深圳-Eiya ： 这么明显的影响开发效率

深圳 - 莲 ： 分支的版本规划要细致，合并时间要规定好，一般两个礼拜。 合并分支的 checklist 要明确

杭州-andy ： 我感觉还是规划的有问题

杭州-dcwang ： 多个并行分支开发，建议把主干提交权限关闭。

杭州-andy ： 估计他主干也是同步进行开发的

深圳 - 莲 ： 分支主干的规划有问题。

昆明-sophia ： 为什么要开分支呢？

杭州-andy ： 我也是这么想的

昆明-sophia ： 是怎么规划的？

北京 - 恐龙 ： 要分支并行开发就并行开发，主干别动

杭州-andy ： 你们分支都要同步主干的代码，那就没必要拉分支 要么就是关闭主干

北京 - 恐龙 ： 分支测试，验证通过再向主干合并 主干作为代码基础点，最好不要做小 bug 修改 代码如果没有修改完毕，有分支需要合并，那么就会有问题 小 bug 小需求，可以和现有即将发布分支合并开发 开并行分支原因在于 需求的并行开发 分支上线必须合并进入主干，要不然要主干就没意义了，主干是分支的起始点

昆明-sophia ： 就是说你们的分支功能类似：FS 分支 是为了开发新的功能做的

北京 - 恐龙 ： 起始点 这个意义决定了主干需要存在，稳定存在

杭州-andy ： 我有点想不过来了 如果有 A B 分支 ，A 合并到主干，主干就变了，变了的主干对于 B 分支就不一致了

北京 - 恐龙 ： 代码分支策略需要根据产品需求特性来指定

杭州-andy ： 那 B 再合并到主干，可能就有冲突了

北京 - 恐龙 ： A 合并 要同步合并到 B 和主干

杭州-andy ： 喔，这样就理解了

北京 - 恐龙 ： 这样才能保证 B 上线发布时，不会缺少 A 的功能

昆明-sophia ： 那如果有 123456.。。个分支，光合并就疯了

杭州-andy ： 而且按照他的说法。。可能是有这么多分支

北京 - 恐龙 ： 要合理开分支 就是为了防止 123456 这种情况

杭州-andy ： 到时候估计很乱

上海 - 如意 ： 分支最好少开

北京 - 恐龙 ： 需求合并，谨慎开分支

昆明-sophia ： 感觉项目规划上有问题

北京 - 恐龙 ： 这个不仅考验 scm 的意识，更考验的是产品经理和项目经理 需求规划的能力

建议，如果能在聊天内容基础之上再提炼总结一下要点，就更好了。

相比于持续集成，我其实更认同持续构建或者叫自动构建。

支持。 关注楼主的进展。 其实我之前也有过类似想法。。。 :lol

3, 5

我投不了票。

权限不够吗？

用的 firefox