代码版本管理

王金城大约 8 分钟

我们选择使用 SVN 为代码版本管理工具，虽然它在分支管理上远远不如 Git 强大，但是为了降低学习成本以及我们的团队大小，我们还是选择了 SVN。

注意

SVN 在切换分支时会莫名多出一级目录，切记不要使用切换分支功能，直接选择所在分支目录获取代码即可。
创建合并分支的操作一定要要使用 TortoiseSVN 在资源管理器中进行操作，不要使用 IDE 中的功能操作。
为了更好的 diff，前端建议使用 Prettier 进行格式化。强制换行 120 列，开启保存时自动格式化。

分支管理规则

代码分支我们分为开发分支和存档分支。存档分支独立存贮在 tags 目录下，作用为留存各个版本的代码。开发分支均在 branches 目录下，分为主线分支、版本分支、定制分支。

由于 IDE 只能显示文件夹名称，防止修改错分支，我们会使用 _ 来分割项目名和分支名。前面时项目名，后面是分支名。

分支	用途	说明
`*_master`	主分支，开发最新功能	一段时间内的新功能均在这个分支中开发，发版会生成最新的 tags 分支。
`_v.*.x`	次版本留存分支	由 master 分支生成，每次发版后生成一个版本分支。
`*_wan-da`	定制分支	由最新的版本分支生成，用于定制功能。
`tags`	存档分支，只读。	从主分支生成，每次发版后生成一个 tags 分支。

代码目录布局

我们以 basic-paper-cloud 为例，代码目录布局如下：

BasicPaperCloud
├─ branches                                # 分支目录
│  ├─ master                               # 主线代码目录
│  │  ├─ basic-paper-cloud-server_master   # 主线 server 代码代码目录
│  │  └─ basic-paper-cloud-web_master      # 主线 web 代码代码目录
│  ├─ v1.0.x                               # 1.0.x 版本分支目录
│  │  ├─ basic-paper-cloud-server_v1.0.x   # 1.0.x server 代码目
│  │  └─ basic-paper-cloud-web_v1.0.x      # 1.0.x web 代码目录
│  ├─ v1.1.x                               # 1.1.x 版本分支目录
│  │  ├─ basic-paper-cloud-server_v1.1.x   # 1.1.x server 代码目录
│  │  └─ basic-paper-cloud-web_v1.1.x      # 1.1.x web 代码目录
│  └─ wan-da                               # 定制分支目录
│     ├─ basic-paper-cloud-server_wan-da   # 定制分支代码目录 server 代码目录
│     └─ basic-paper-cloud-web_wan-da      # 定制分支代码目录 web 代码目录
└─ tags                                    # 存档分支目录
   ├─ v1.0.0
   │  ├─ basic-paper-cloud-server_v1.0.0
   │  └─ basic-paper-cloud-web_v1.0.0
   ├─ v1.0.1
   │  ├─ basic-paper-cloud-server_v1.0.1
   │  └─ basic-paper-cloud-web_v1.0.1
   └─ v1.1.0
      ├─ basic-paper-cloud-server_v1.1.0
      └─ basic-paper-cloud-web_v1.1.0

主线分支

主线分支是开发的最新功能代码。当需要发布新版本时，一共要做三件：

创建一个版本分支。如：basic-paper-cloud-server_v1.0.x。
创建一个 tags 分支。如：basic-paper-cloud-server_v1.0.0。
当前分支次版本 +1 并归零其他版本进入新的开发。如：1.1.0.0

版本分支

一定是次版本的稳定版本，停止任何不兼容的功能开发，后续多为修改 bug 使用，如果需要新功能尽量使用最新版本。
一定是当 master 分支代码稳定后生成的分支，如 basic-paper-cloud-server_v1.0.x、basic-paper-cloud-server_v1.1.x。
当修复对应版本的 bug 时，直接在对应的版本上开发，稳定后生成 tags 分支。

修订 bug 举例

当我们发现现场的项目存在 bug 时，查看现场的版本号。假设现场的版本是 v1.1.2，这时会有两种情况：

现场不是最新版本，已经在 v1.1.4 中修复了这个bug。这时我们只需重新打包 v1.1.x 的最新版本直接发布即可。即：如果最新版本为 v1.1.6 那么就直接更新 v1.1.6。
这个 bug 是最新的我们需要修复，那么需要在 branches 中的 v1.1.x 分支上开发，开发完成后生成 tags 分支，版本号为最大版本号加 1。如果最新的版本号为 v1.1.4，那么生成的 tags 分支为 v1.1.5，并使用 v1.1.5 进行本次更新。

如果其他版本中也存在相同的 bug，那么需要将代码合并到对应的分支中，测试通过后同样要产生新的 tags 分支。如果主线分支也存在这个 bug 合并到主分支即可，等待下次主分支发版。

定制分支

当某个项目无法通过配置的手段完成通用性兼容时，我们会创建一个定制分支，如 basic-paper-cloud-server_wan-da。此分支将不会添加任何通用功能，只会添加定制功能和 bug 修复。

定制分支是不用生成 tags 分支的，因为只针对这一个项目，留存档没有实际意义。直接在定制分支上打包发布即可。

tags 分支

这个目录下的每个次版本的最大版本号的代码一定时目前最稳定的版本。
项目上线的安装包一般都产自这里，会采取最新的版本进行发布。
禁止修改这个目录的代码，如果需要修改，需要在 branches 中对应的版本分支上开发，开发完成后生成 tags 分支，版本号为最大版本号加 1。

版本号说明

我们的版本号分为 x.y.z.a 的四级结构，例如：1.0.0.0。

x 主版本号，当大版本号改变时，说明该版本与上一个版本完全不兼容。一般只有产品重构后才会修改，例如：几乎所有的模块都有颠覆性的修改。
y 次版本号，当次版本号改变时，说明该版本与上一个版本存在不兼容。一切存在不兼容的情况都会修改，例如：数据库结构有改动（包括新增、修改、删除表或表字段）、新增或删除了某个模块、新增或修改了某个模块的功能等。
z 修订号，当修订号改变时，说明该版本与上一个版本兼容。例如：修复 bug、优化代码、漏洞修复（包括以来版本的漏洞升级）等。
a dev 版本号，这个版本号只存在开发和测试阶段，发版时需要去除 dev 版本号。例如：1.0.0.13 将被合并到 master 分支后，版本号将变为 1.0.0。