请教各位达人：

在一个30个软件开发工程师左右，4/5个开发组条件下，做一个软件开发项目，软件周期在6个月左右

用的配置管理系统是clearcase base系统

求教大家对于拉分支的策略有什么好的经验分享？

从我这边的观点看

1。版本发布分支始终是要保持一个

2。开发分支怎么处理？有些建议是每出一个版本就基于最新版本标签新给一个开发分支，还是保持一个稳定的开发分支贯穿始终比较好？

3。MR分支，有要求每一个MR拉一个分支来处理，有些赞成对于较严重的MR拉独立分支，也有建议是每出一个release，就新建一个统一的MR分支，就各位经验，怎么做比较适合？

4。对于每个软件开发者自己的单元测试和报告是，要求他merge到总的开发/MR分支之后做，还是之前做？还是都要做？

5。对于一些关联性较强，影响性较高的模块，怎么做配置管理比较好？

望各位有经验的来看一下

可以利用3层分支法：
主分支：用于存放基线
集成分支：存放验证过的、团队认可的改动！
研发分支：存放研发人员自己的代码！

对于快速开发可以基于latest来开发，对于对质量要求较高的开发可以基于label来开发！

看了听雨的回复，觉得对。但是还是不好理解，觉得空洞。要是能看到你拉好的分支就好了。听雨，有截图吗？
okey，MR的全称是什么？

1、根据你的项目规模来看，可以考虑使用多个发布分支
     比如说，1.0、2.0、3.0之类大的版本使用主线，1.1、2.0.1之类的小版本可以使用各自单独的分支

2、根据第一项的情况，个人建议每个版本使用单独的开发分支

3、每个MR都使用各自的分支比较合适

4、单元测试我们是在代码合并之前做的，测试通过了才允许合并并且打标签

5、不太理解

首先说明一下MR是指modification request，变更请求，我表述时特指bug

然后还是要求教一下
听了上边的解释，还是觉得有点空
目前软件开发的环境是在一个大版本过程中的许多个小版本的配置管理
其中对于新的小版本发布后，原先拉的分支各位是如何处理的？
对于有些软件模块可能要跨几个小版本才能合并到集成分支的，又怎么处理是最佳选择？
感谢楼上各位发言支持

1. Main - QA - IT - dev1-bug1
                  - dev2-bug2
                  - dev3-bug3
                  - dev4-bug4
2. Before performing merge, do merge back first.
3. Lable all releases
4. Merging, dev to IT may or may not controlled. But IT - QA, QA - main must be controlled.
5. For every MR, you may start a new one.

关注。大家都是怎么用分支的，本人还需要学习和理解，就不发表意见了

分支，还是依据版本计划来建立，也要合理规划，首先要制定一个分支策略，以免分支过多而增加维护、研发成本。
1，任何时候都需要保证Main是稳定的。
2，建立测试验证分支，主要用于验证新合入的代码是否OK，如新增加了的模块、新增加了需求、新增加了特性、修正系统BUG的代码等。
3，建立发布分支，主要用于发布版本，同时可以并行开发。发布分支可以验证发布版本是否OK，Main同时可以进行新的开发。
4，建立补丁分支，用于合入补丁代码，发布补丁版本。
5，其他，根据实际来建立合适的分支。
欢迎指点~

分支，建议基于某个Label来建立，不要基于Latest建立，主要是便于查阅和回溯。

再加一个：集成分支 ：）

看了还是不是很明白,我会继续关注这个问题,直接明白为止
谢谢楼主提供这个讲论的空间