trunk和branches的那些事---很多SCM都没弄明白的

最近生病导致博客又没更新，没办法，虽然工作大量的实用自动化。但是偶尔有点事情还是要人来解决。

成都天气又多变。。哎。。。病的不轻。

今天一早就跟一个同行讨论了下“合并分支”，虽然我项目上没有这个词语。但是从back to the point的角度出发，这个“合并分支”就是让trunk和某branch保持一致的代码的事情。

今天又有空就来念叨念叨这个。

老规矩，上图。

这里举个例子，假设微软开发一个windows in future 的系统。基于上次写的trunk,branch的规则。

这里的branch 1.0就是第一个可以交付用户A使用的版本，那么这个branch上做完测试后，会打tag来发布。

用户A收到这个版本后肯定会大大的使用一番，并且提出很多新的改进要求以及提出软件BUG所在。

我们的团队要做啥呢？

第一个就是把BUG修复，把新的要求加入到新需求中进行开发。然后把bug的correction，必须同时提交到branch 1.0和当时最新的trunk上。即使trunk代码跟branch1.0可能会有很大出入，也必须重构correction以后提交trunk。

那么trunk上就有了branch1.0找出来的bug所对应的新correction.

在看看新需求，新的需求，要记得在trunk上开发，因为trunk时刻在更新，你的把新东西丢到新的上面。开发完后，记得把整个feature提交trunk，并且做tag出来让测试团队测试，测试过了，你的新feature才算OK了。

那么此时的trunk已经包括了branch1.0上面所有被客户提出的新需求、新bug的correction。是时候拉个branch2.0给客户A使用了。客户一定会再次提出新的需求，新的bug，那么我们的团队需要把上面的事情，再来一遍。

直到什么时候？直到客户满意的时候：）。

有人一定问，我的软件N个客户使用肿么办？

我想说的是，一个客户的你研究懂了，多个客户的只是多做几遍重复的事情而已了。嘿嘿。为啥我喜欢说而已，因为咱SCM懂自动化啊！哈哈！