呵呵~好的

谢谢 konglong 和 xiaoxiang ~

北京恐龙: 基线库 ，文档、代码 产品库简单点就放成功的软件 北京-wshzhn: 不太确定包括哪些文档内容 想一些评审报告之类的能纳入基线吗？ 北京恐龙: 评审报告作为一个中间性文件，可以不放入基线 但是作为一个入基的证据，应该保存起来 北京-wshzhn 保存是指怎么操作？只入开发库就行了是吗？ 北京恐龙 放入普通文档存档目录 这些都是我公司目前管理的方式 北京-xiaoxiang: 我觉得你需要考虑的事情是你们的东西应该放在哪个库里面 而不能简单的问库里面应该包含哪些东西。 毕竟公司要求都不一样的 北京-wshzhn: 我是在想那些东西应该放在哪儿，正在写规范。 北京-xiaoxiang: 对头~ 北京-wshzhn: 目前所有的文档都会放到开发库里边，但是不确定纳入基线 时候要不要把它们一起放进去。 还有产品库里边要不要放评审报告什么的。还是说这些都没有什么规定，只看老大和开发人员有什么样的需求？ 北京恐龙: 你们的代码和文档不是分开存放？ 北京-wshzhn: 不是，在同一个库里，分代码和文档两个目录，然后文档里边又分具体的目录结构。 北京恐龙: 那你还有什么疑问吗？ 不属于代码的就放文档目录 成品软件放入产品库 文档库可以有基线文档目录 代码库可以有基线代码目录 北京-wshzhn: 在开发库里边是很清楚，但我还是不知道要不要把评审报告什么的纳入基线。 北京恐龙: 不需要 那是一个证据 留个存档就 OK 北京-wshzhn: 那产品库里边呢？放的是需要发布给客户的所有文档和最终软件是吗？一些类似于需求、设计之类的不需要放到里边吧？ 恩 北京_恐龙: 需求设计这些属于公司的无形资产，不应该放 北京-wshzhn: 噢。

[[i] 本帖最后由 laofo 于 2010-11-24 21:59 编辑 ]

不知道你说的这个比较独立的程序 AAA 跟产品是不是在同一个库里？像我公司正式发布时把平台作为一个产品，里边有各个产品线，但是各个产品线都单独一个库。觉得你描述的这个更像是在同一个库里的。 如果是在同一个库里，我觉得就给这次解决 bug 创建一个临时 HF 分支，解决完发布补丁包后合回通用的 HF 分支，然后临时的 HF 分支可以删除，因为以后不需要维护它，毕竟出现它自己紧急问题的情况不多，一直维护这个分支的话需要总把通过的 HF 分支合过来；不过为了保证可追溯性，留着它倒是也无妨。再出现像这样某个单独的程序有紧急情况，都可以临时开个分支来解决。 如果每个独立的程序都是单独的库，即使跟产品一起发布，在各自的库里肯定也有一条自己的发布分支，那么就在发布分支的 3.0 发布标签处开一个 HF 分支，以后一直维护，需要自己单独发布补丁包的话直接发布即可，需要跟产品一起发布的时候从该分支上取相应版本集成。

No Problem. 碰钉子了上来让你先鄙视 + 嘲笑一番，然后请你支支招╭(╯^╰)╮

吼吼~好吧。头疼的问题。 不过他们最近吃了分支的苦，我顺势推一下，希望可以顺利些。

:o 还以为你能给有啥想法，看这个方法是否存在大的弊端呢

嗯，好的。 你觉得这个分支策略可行吗？帮我分析一些可能出现的问题吧。我到时候跟他们讲的时候针对利弊都全面的分析一下。

R 表示 Release，正是发布的版本； T 表示 Test，提测的版本； P 表示 Patch，补丁包版本。 在图的那楼加上这个说明了。

是想发布和提测都在 main 分支上，补丁在维护分支上，所以没有按照版本级别划分分支。

[[i] 本帖最后由 wshzhn 于 2010-11-18 11:28 编辑 ]

是，谢谢你帮我检查出一个错误。替换图片了

还没呢，刚把文档发给我老大看，他觉得没有问题了，就可以让大家讨论了。 你觉得这个分支策略哪里不合理是吗？请说说看。

我是想先控制创建分支，不得不开时才开，开了分支后，就要根据两个的关系，定期进行 merge，至少提测通过后需要 merge，这个工作应该是我跟他们一起完成的，他们比以前多的工作就是要记得提测通过后及时 merge。以前他们没有这个概念，所以都是一个分支开了以后就一直做，到最后这个分支上的工作开发完了，可能几个月了，然后才合回主开发分支，导致合并的时候特别麻烦，合并后还需要调试很久，这几天有两个组都是这种情况了，一个组 merge 了 849 个文件，另一个组 merge 两三千个文件，我看着都头疼。他们也知道不定期合并的痛苦了，我估计以后让他们做的时候应该比较容易接受吧。我开始的时候肯定要督促一段时间的，让他们养成习惯应该就好了。

[[i] 本帖最后由 wshzhn 于 2010-11-18 01:49 编辑 ]

哇哈，谢谢 i 子休 O(∩_∩) O

PS：今天太忙都忘记说了，对这个分支策略有什么意见，请大家帮忙提哈

[[i] 本帖最后由 wshzhn 于 2010-11-16 18:32 编辑 ]

开始保存成 jpg 的格式，质量很差，又保存了一个 png 的上传了，这个应该可以了。不过以前的那个 jpg 的附件我删除不掉，你如果可以的话帮忙删除吧。

下图是我初步定的分支策略，图很难看哈，大家将就下吧，我实在不会画图 [attach] 917[/attach] [size=10.5pt] 说明： R 表示 Release，正是发布的版本； T 表示 Test，提测的版本； P 表示 Patch，补丁包版本。

[size=10.5pt] 基本思路是： [size=10.5pt] 有一个主开发分支和一个发布分支，计划发布的市场版本都在主开发分支上，该版本的提测和发布都在发布分支上；其他版本的需求都在发布分支的某个版本处开分支。

[[i] 本帖最后由 wshzhn 于 2010-11-18 11:27 编辑 ]

xiaoxiang7788 于 2009-7-2 10:10 发表

这个是一点都不夸张的。一个大型的项目，如果做到了组级别的个人化持续集成，它所带来的工作效率和对产品质量的保证是一般的持续集成不能比拟的。而且每个小组所负责的模块是不一样的，在做小组集成的时候一定要基于 ... [/quote]

xiaoxiang，你说的这里我有点儿不太明白。要实现你说的这种，是不是一个代码库里边要把模块分的很清楚，模块儿之间都不存在耦合才行？每个模块儿的 dev 都检出自己要修改的代码，直到组内验证通过了再提交。但是即使是组内在一同一个模块儿内，也不能及时得到组内其他人修改的代码啊，如果想及时得到别人的，必须提交别人 update 才行吧？

有，正在整理思路，整理好了上来写我的结论。嘿嘿~~~非常感谢 O(∩_∩) O

我哭，我在写分支管理规范，现在分支创建的比较混乱，大家使用不方便，维护分支也不方便，所以想定一个基本的创建分支的原则，有特殊需求的时候再根据具体情况考虑，公司一般正常的发布的流程下基本都按照统一的规则创建分支。如果预研的话周期也太长了，一次发布到下一次发布要很长时间的。所以想问下大家对于我描述的这种流程情况下，什么样的分支策略比较合理。 主要是想规则基本定了，他们让给开分支的时候我就可以说按照规则应该怎么建分支，就不会出现现在这种他们很多分支以前乱开，用着用着发现很不方便，合并之类的操作都非常麻烦，现在他们很头大，然后跟我说是历史遗留问题。O__O"…

对了，开发人员包括项目经理在内，可以有创建分支的权限吗？

你的意思是，在当前预发布版本还没发布的情况下，最好不要开始下个版本的开发工作？

“对于后期发现 2.0 版本的 bug，如果 3.0 没发布，那么就在 2.0 基础上拉出分支，修改 bug 发布，代码合并到 3.0 一份。 如果 3.0 已发布，那么就在 3.0 基础上拉出分支，修改 bug 发布。” 你说的这种做法，2.0 的维护分支上修复完 bug 后合到 3.0 分支上之后，2.0 的维护分支会删除吗？

你说的测试版本的分支，我现在也在考虑是否有必要。完全可以直接在 dev 分支上，他们说要提测，我就打个标签，然后在编译机上按照标签取代码进行编译。但是以前就一直是这样做的，需要提测先 merge 到 test 分支上，从 test 分支上出测试版本，然后打标签，可能他们觉得有个分支一直保留一份稳定的版本比较好，标签维护起来也比较方便，不会 dev 上标签太多。但是 merge 的过程确实也增加了一层风险。我先记下了，跟他们讨论一下。 别人提测的时候都是怎么做的？都是在开发分支上直接打标签，然后出版本吗？ 如果是直接在开发分支上打标签出测试版本的话，那么对于发布版本，会专门创建一个分支，每次发布都 merge 过去吗？

就是 i 子休说的意思。

clearcase

要提前对下个版本进行规划，在当前版本还未发布时，可能下个版本就进入开发了，所以会在当前预发布版本的某个稳定版本上开出下一个版本的分支，当当前预发布版本发布后，由于是主干发布的模式，所以会把下个版本的分支 merge 到预发布版本开发分支上。

所有分支都保留是没太大影响，就是觉得可能发布版本多了，会有很多维护分支，所以不清楚要不要保留，想看看大家都是怎么处理这种情况的。

就是很复杂，所以我头都大了，赶紧帮我想想办法。不过可能是我表达能力差，所以描述的复杂了，你仔细看看明白我说的意思了，应该挺好理解的 (^__^) 嘻嘻……

非常感谢 xiaoxiang 帮我发了帖子并给我回答 O(∩∩) O 但是强烈抗议你们吃饭的时候从来不带我，现在又来欺负我这菜鸟~~~~(><)~~~~

回正题： 我公司目前的情况是都在一个分支上开发市场版本，比如分支名为 dev，我想的是，以后当前预发布版本都在 dev 上开发，比如现在预发布版本为 2.0，还没有发布，然后规划好了 3.0 版本了，也要开始开发，那么给 3.0 版本基于 dev 创建一个分支，当 2.0 版本开发完成发布后，把 3.0 分支的代码 merge 到 dev 分支，然后 3.0 的分支删除，就是始终保持 dev 是市场预发布版本，不知道这个是不是 xiaoxiang 说的主干发布模式？ 对于我说的这种模式，2.0 已经发布，以前的开发 2.0 的分支已经不存在了，如果出现 bug 如何维护？xiaoxiang 的意思是在 2.0 发布后在 dev 上打个标签，然后根据标签创建一个 2.0 的维护分支 2.0maintenance ，专门用于 bug 的修复，bug 修复后要把代码 merge 回 dev，对吗？如果这样的话，2.0maintenance 分支是要一直保留的吗？ 如果说 3.0 版本开发完成后发布了，里边已经包含了对 2.0 上的 bug 修复，2.0maintenance 是否还需要继续保留？我开始以为这个是要根据实际情况，看是否会对市场上的 2.0 版本持续维护，如果持续维护，毫无疑问需要保留该分支；但是如果不维护了，是否就应该删除了呢？如果删除的话，肯定在 2.0maintenance 上每次解决一批 bug 出了补丁包后都会打一个标签，如果该分支删除了，那么这些标签对应的代码以后也取不到了。所以这里不太清楚维护分支是否有必要一直保留？ 第 2 个问题，我说的构建分支的意思是，专门有一个分支用于出测试版本。我公司是都统一在 dev 分支上开发，然后需要提测的时候 merge 到 test 分支上，然后从 test 分支上出测试版本。其实这里不太清楚有没有这样做的必要，是不是只有一个 dev 分支就行，需要提测的时候先在 dev 分支上打标签，然后根据标签取代码，然后做 build。请问你们构建的时候通常是怎么做的？ 如果你们的开发分支和构建分支都是一个分支的话，就不存在我说的为每个版本的分支再创建一个相应的构建分支的问题了。 但是有另外一个问题，比如说 2.0 发布后把 3.0 版本 merge 到 dev 分支了，3.0 要删除吗？它以前提测的时候在 3.0 分支上打了标签，如果删除了根据以前的标签取不到相应的代码了。你们是怎么处理这种情况的？

我说的比较混乱。你们将就着理解一下吧。O(∩_∩) O 谢谢

[[i] 本帖最后由 wshzhn 于 2010-11-9 10:01 编辑 ]

今天下午开会讨论了，最终决定按照我的方案对文档进行版本控制了，会上大家都很给力，吼吼~~

也谢谢坛友们给我很多好的建议，虽然我在会上讲的时候还是语无伦次，老大不能忍了还教我先说什么、再说什么，而且通常只有两个 PM 能听懂我说什么，我表达能力太差了，他们得帮我翻译成别人能听懂的 o(╯□╰) o

不过最终解决这个难题了:D