在参加一个行业展会的准备期间, 我们从主干分支上拉出了一个分支专门为这个展会产生一个稳定的版本, 只有与展会有关的bug, new feature才会出现在这个分支上. 等展会过后, 再把这个分支上的工作全部同步到主分支上, 同时禁用该分支.
这在理论上听起来不错, 实际操作中碰到下面的问题:
1. 有一些文件你不希望在两个分支上维护.
2. 开发人员在主分支上做refactor类似的修改, 比如rename, 这样的修改, 如果是对C#, 在工具支持的比较好的情况下, 可以说是非常安全的, 但对C++危险一些, 最要命的是, 这样的修改过后, 在合并工作分支时几乎一定会带来冲突, 因为这样的修改是零散的.
3. QA报告来的Bug 中没有明确说是需要在行业展会的临时分支上解决的, 而开发人员假设是在主分支上工作, 这样, 就出现一些本应在临时工作分支上的修改被提交到了主分支上, 发现这一点时, 修改已经提交了, 这就需要开发人员把主分支上的修改merge到工作分支上, 这种操作为后来的merge带来麻烦.
4. Review, 在合并分支之后, 最好由最初在工作分支上作出相应修改的开发人员, review一下自己在工作分支上的修改, 是否被正确合并到了主分支, 如果整个项目改动总体量比较大, 不适合项目中单个人来负责整个的合并后Review工作, 应该把Review的任务分摊给每个相关人, 在这里交叉Review 不如自己Review自己的工作来得更好, 因为这种Review的目的只是保证一个分支上的工作被正确合并到了主分支上. 而交叉Review 需要理解他人的代码, 带来不必要的沟通成本.
如何分配这个工作量呢? 或者说如何把需要Review的文件列表交给每个开发人员呢?
cvs log -rBR_TEMP_Working -N -S . | tee temp_branch.txt
这个命令把分支 BR_TEMP_Working 上所提交的每个 revision都保存在文件
temp_branch.txt 中, 每个revision中保存有提交者的名字, 据此可以知道某个文件是否被某个开发者修改了. 有可能出现一个文件被不同的开发者提交多个版本.
通过用vim 对该文件作简单处理, 可以得到某个开发者所应负责Review的自己的文件列表.
具体在Review时, 每个开发者需要作的是:
A) 查看主分支上该文件的最新版本, 同时用比较工具打开该文件的一次特定的check in所对应的revision, 与该revision的前一个revision进行比较. 举个例子:
工作分支在 a.cpp文件的 1.6 版本上分叉, 发展出了
1.6.2.1 zhang
1.6.2.2 wang
1.6.2.3 zhang
1.6.2.4 li
这4个版本, 假设合并后主分支上最新文件为1.7 版本(合并而且提交之后的版本), 那么对开发者 zhang来说, 需要比较
diff 1.6 1.6.2.1
查看这两个版本的不同, 与源代码编辑器中的打开的1.7版本对比, 看从1.6 到1.6.2.1的修改是否合并到了1.7版本.
diff 1.6.2.2 1.6.2.3
同上.
或许应该有一个小工具, 自动在一次合并后, 生成每个开发者应该Review的文件列表.
阅读(878) | 评论(0) | 转发(0) |
