大家好，又见面了，我是全栈君，今天给大家准备了Idea注册码。
例如，该项目是proj。svn地址svn://proj/，然后该标准svn布局是
svn://proj/ | +-trunk +-branches +-tags
这 是一个标准的布局，trunk为主开发文件夹，branches为分支开发文件夹，tags为tag存档文件夹（不同意改动）。可是详细这几个文件夹应该怎样使 用，svn并没有明白的规范，很多其它的还是用户自己的习惯。
对于这几个开发文件夹。一般的用法有两种。我很多其它的是从软件产品的角度出发 （比方freebsd），由于互联网的开发模式是全然不一样的。
第一种方法
使用trunk作为基本的开发文件夹。
一般的。我们的全部的开 发都是基于trunk进行开发。当一个版本号/release开发告一段落（开发、測试、文档、制作安装程序、打包等）结束后。代码 处于冻结状态（人为规定，能够通过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。当下一个版本号/阶段的开发任务開始，继续在trunk 进行开发。此时，假设发现了上一个已发行版本号（Released Version）有一些bug，或者一些非常急迫的功能要求，而正在开发的版本号（Developing Version）无法满足时间要求，这时候就须要在上一个版本号上进行改动了。
应该基于发行版相应的tag，做相应的分支（branch）进行开发。例 如，刚刚公布1.0。正在开发2.0。此时要在1.0的基础上进行bug修正。
依照时间的顺序
1.0开发完成，代码 冻结
基于已经冻结的trunk，为release1.0打tag
此时的文件夹结构为
svn://proj/
+trunk/ (freeze)
+branches/
+tags/
+tag_release_1.0 (copy from trunk)
2.0 開始开发。trunk此时为2.0的开发版
发现1.0有bug。须要改动，基于1.0的tag做branch
此时的文件夹结构为
svn://proj/
+trunk/ ( dev 2.0 )
+branches/
+dev_1.0_bugfix (copy from tag/release_1.0)
+tags/
+release_1.0 (copy from trunk)
在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发
在1.0 bugfix 完毕之后，基于dev_1.0_bugfix的branch做release等
依据须要选择性的把 dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要依据详细情况）
这是一种非常标准的开发模 式。非常多的公司都是採用这样的模式进行开发的。trunk永远是开发的主要文件夹。
另外一种方法
在每个release的branch中进行 各自的开发。trunk仅仅做公布使用。
这样的开发模式其中，trunk是不承担详细开发任务的，一个版本号/阶段的开发任务在開始的时候。依据已经 release的版本号做新的开发分支，而且基于这个分支进行开发。还是举上面的样例，这里面的时序关系是。
1.0开发，做 dev1.0的branch
此时的文件夹结构
svn://proj/
+trunk/ (不担负开发任务 )
+branches/
+dev_1.0 (copy from trunk)
+tags/
1.0开发完毕，merge dev1.0到trunk
此时的目 录结构
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
+dev_1.0 (开发任务结束。freeze)
+tags/
依据trunk做1.0的tag
此时的文件夹结构
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
+dev_1.0 (开发任务结束，freeze)
+tags/
+tag_release_1.0 (copy from trunk)
1.0开发。做dev2.0分支
此时的文件夹结构
svn://proj/
+trunk/
+branches/
+dev_1.0 (开发任务结束，freeze)
+dev_2.0 （进行2.0开发）
+tags/
+tag_release_1.0 (copy from trunk)
1.0有bug，直接在dev1.0的分支上修复
此时的文件夹结构
svn://proj/
+trunk/
+branches/
+dev_1.0 (1.0bugfix)
+dev_2.0 （进行2.0开发）
+tags/
+tag_release_1.0 (copy from trunk)
选择性的进行代码merge
这事实上是一种分散式的开发，当各个部分相对 独立一些（功能性的），能够开多个dev的分支进行开发。这样各人/组都不会相互影响。比方dev_2.0_search和dev_2.0_cache 等。可是这样merge起来就是一个非常痛苦的事情。
这里要注意一下的。第六步进行选择性的merge，是能够当2.0开发结束后一起把 dev_1.0（bugfix用）和dev_2.0（新版本号开发 用）merge回trunk。
或者先把dev_1.0 merge到dev_2.0，进行測试等之后再merge回trunk。
这两种方法各有利弊，第一种方法是能够得到一个比較纯的dev_2.0的 开发分支，而另外一种方法则更加的保险。由于要測试嘛。
以上呢，就是我说的两种开发模式了，详细哪种好，并没有定论。这里大致的说一下各自 的优缺点。
第一种开发模式（trunk进行主要开发。集中式）：
长处：管理简单
缺点：当开发的模块比較多，开发人数/小团队比較多 的时候。非常easy产生冲突而影响对方的开发。由于全部的修改都有可能触碰对方的修改。
另外一种开发模式（分支进行主要开发，分散式）：
长处：每 自独立的发展，不easy相互作用。
缺点：管理复杂，merge很麻烦的时间，easy死。
其实，而不是明显的在这里。许多其它时间两种 模式组合。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/117762.html原文链接：https://javaforall.net
