在SVN里面我们一般会创建出三个文件夹
Trunk(主干) Branch(分支) TAG
在我们项目一开始的时候我们会将代码文件 (这边暂时不涉及文档的管理)放在Trunk底下。然后我们就不断的开始工作了。
什么时候我们会用到Branch。
按我的经验的话我们用到Branch有两种情况
项目稳定了要relase了 整个业务流程和功能都是完成的。(基本看不到bug只有一些隐藏的很差的bug可能还存在,比如一些数值算错)。这个时候我们就可以把这个Relase的版本放到Branch哪边,然后我们继续在trunk开发新的功能需求。 relase哪边只能是等待一些很小的bug。 (测试和开发做得好的话。无限趋近0零)。
项目开发过程中,突然有一个大的需求过来。跟其它的需求没有太大的关系。并且客户想看一下这个功能做出来是否用得还可以。哪么我们就可以从trunk这边弄出一个branch然后,某个人或几个人就工作在这个branche上面。客户测试过后对这个Branche满意之后。(也是大部分没有bug)。然后合并到trunk.
如果branch的创建没有按这种方式来搞的话。你会发现到时候合并起来的压力是超级大的。合并的时候会漏掉一些代码,冲突N多。合并的人痛苦。团队的其他成员也痛苦。
TAG 我自己基本没有什么用到。按大部分人的说话是这样的。
一个Relase发布之后。经过一小段时间的修改。发现都没有bug了。然后我们把这个Relase可以弄一个分支到Tag哪边。实际我觉得这个意义不是很大。
Trunk(主干) Branch(分支) TAG
在我们项目一开始的时候我们会将代码文件 (这边暂时不涉及文档的管理)放在Trunk底下。然后我们就不断的开始工作了。
什么时候我们会用到Branch。
按我的经验的话我们用到Branch有两种情况
项目稳定了要relase了 整个业务流程和功能都是完成的。(基本看不到bug只有一些隐藏的很差的bug可能还存在,比如一些数值算错)。这个时候我们就可以把这个Relase的版本放到Branch哪边,然后我们继续在trunk开发新的功能需求。 relase哪边只能是等待一些很小的bug。 (测试和开发做得好的话。无限趋近0零)。
项目开发过程中,突然有一个大的需求过来。跟其它的需求没有太大的关系。并且客户想看一下这个功能做出来是否用得还可以。哪么我们就可以从trunk这边弄出一个branch然后,某个人或几个人就工作在这个branche上面。客户测试过后对这个Branche满意之后。(也是大部分没有bug)。然后合并到trunk.
如果branch的创建没有按这种方式来搞的话。你会发现到时候合并起来的压力是超级大的。合并的时候会漏掉一些代码,冲突N多。合并的人痛苦。团队的其他成员也痛苦。
TAG 我自己基本没有什么用到。按大部分人的说话是这样的。
一个Relase发布之后。经过一小段时间的修改。发现都没有bug了。然后我们把这个Relase可以弄一个分支到Tag哪边。实际我觉得这个意义不是很大。