版本管理方式简单5句话

主干是已上线代码，分支是开发中代码
主干是1.1版本，拉出1.2,1.3分支版本同时开发
1.2上线了。合并1.2到主干。主干已经是1.2的版本
1.3准备上线。主干拉出1.4分支版本，从主干1.1版本，到主干1.3版本之间的差异合并进来。
1.4版本就是合并后的版本。

都不知道你讲什么

这种模式适合于产品性质的开发；

而项目则不同，项目上线，不一定意味着1.1版本的结束；1.2版本在开发的时候，有可能客户会让你马上调整一个已经上线（1.1版本）的功能；
这个时候，你如果告诉客户，1.2版本给他上，他认为时间太长；
所以，你不得不在主干（1.1）版本上修改。而后同时提交两份。。还要考虑1.1版本的回归测试。。。

这个也在范围内吧，客户的调整需求也是一个分支。相当于1.3吧。最后是1.2上还是1.3上，还是分支合并的问题。

对于这个版本控制模式，我有几个疑问：
1. 为什么1.2和1.3要同时开发？
2. 如果1.2和1.3相差很大，合并到1.4以后BUG谁来改？
3. 在1.4里面发现的BUG,你怎么知道需要在1.2，还是1.3里面也需要修改？


我们的版本控制办法是：
1. 主干上是最新的稳定的代码
2. 开发在dev分支上开发，经过测试可以放到主干
3. 产品开始上线时，拉出相应版本的分支，比如1.2， 1.3， 1.4
4. 各个版本对应的分支上不进行任何的新功能开发
5. 如果在发布的版本上发现BUG，需要在对应的分支上修复，测试通过后，同步到主干

我们的版本控制办法是：
1. 主干上是最新的稳定的代码
2. 开发在dev分支上开发，经过测试可以放到主干
这两条是前提，不过我们有点不一样，主干是上线的代码，分支上线后才合并到主干
回答你的疑问，
1. 为什么1.2和1.3要同时开发？
这里只是说明多个需求同时开发的情况。我想在项目中基本上都这样，很少会一时间只开发一个需求的。可能我没表达清楚，囧
2、1.2和1.3相差很大，合并到1.4以后BUG谁来改？
1.4没上线，项目经理代码审核整理后，提交代码，回归测试，发现BUG，项目成员都可以改，直接1.4分支上改。
1.4是当前主线版本，修复BUG也是个需求，打分支，由项目成员开发。
3. 在1.4里面发现的BUG,你怎么知道需要在1.2，还是1.3里面也需要修改
1.4没上线，则1.2,1.3存在相应的BUG都要修改
1.4是当前主线版本，则没有必要。除非项目经常出现版本回退的情况。

看情况而定吧~~~

确实不知道你要干什么？是给大家介绍你的经验，还是自言自语啊！

也不能这么绝对，有时也需要具体情况而定

各有各的使用方式，我们的使用是这样的：
主干是当前正在开发的代码，标记是已发布版本。对于尝试性的开发和BUG修复都是利用分支。