仓库源文站点原文


title: 如何避免svn合并冲突 date: 2019-01-29 22:13:36 tags: SVN

categories: SVN

svn 给笔者的一大印象就是非常容易产生冲突,特别是项目加入新人后,由于初期没有强硬地制定规范,导致后期合并代码时灾难连天。决定在此分享这些“亡羊补牢”的规则,也算是避免 svn 产生合并冲突的一点经验。

<!--more-->

一个简单的分支管理策略

正式分享 tips 前,先交代一下目前在用的 svn 管理策略,因为本文避免合并冲突的一些要点就是建立在此策略之上的。

类似于 git 的轻度规则,主要分为 dev、master、release 三种分支。

以 master 为核心,保存完整代码。release 则允许剔除未编译前端 js、测试用例、项目文档等运行环境不需要的文件,减轻发布体积。功能开发在各 dev 进行。因此 master 和 release 只需要处理代码合并。

发布分支        主干       开发分支

release1 <-            <- dev
release2 <-   master   <- feature
...      <-            <- ...

如何避免冲突

1. 编辑器装好 svn 相关插件。

不同于“装机必备”的 git ,很多编辑器没有自带 svn 的管理插件,需要用户自己安装。

尤其重要的功能是可以实时对比 diff,本地和远程仓库的差异一览无遗,不要再疑惑为什么本地顺畅线上崩盘了。

windows 开发环境可能需要配置 svn 环境变量,但不要偷懒,这点工作一劳永逸。

2. 细化提交。

当合并时,假如发现同一个提交下存在还未达到上线状态的变更,这种情况如果忽略合并某些代码,会导致该开发分支和 master 分支不再一致,为后继的开发者挖坑。

3. 开发分支也要规范 commit log。

尽管开发分支可能在功能完成后就被删除,依然要有意识地为各个 commit 打上前缀、标签。

假设某开发分支是多人协作,若 commit log 有合适的标签,可以增加合并时的检索效率,避免遗漏部分久远的提交。当然,除非业务关联性较大,放在一个分支方便做同时修改,最好还是分模块、分特性单独建开发分支。

4. 所有的合并操作,采取针对版本号的更改。

其实主要面向需要长期维护的开发分支,直接合并目录树会携带大量不稳定变更。

5. 对完整的分支执行合并。

对整个分支目录执行合并,而不是对单个文件、单个子目录做合并,否则结合第 2 点,这极容易埋下隐患。

6. 牢记发布分支 release 是 master 的快照。

禁止跨过 master 在 release 直接提交代码。更危险的是在 release 提交的代码和 master 不一致,好在上次遇到这么做的被我及时制止了。XD

进一步要求,不要在 master 直接提交解决冲突以外的代码。

7. 定期把 master 的所有更改合并回开发分支。

尤其是涉及工具类、公共模块的更改。当开发分支维护不下去时,以 master 为基准重建开发分支。

8. 遇到 GUI 解决不了的冲突,命令行参数了解一下。

大杀器,说多了都是泪……

小结

以上内容是笔者几乎照搬着对 git 的理解来总结的,可能并不成熟。不过经过了一年的实践,这些“规范”操作的确达到了避免冲突的目的,且远没有复杂过 git rebase 工具流。

制定规范是一回事,更应该要求团队成员继续加深对版本管理库的理解,思考分支合并存在的意义,养成更好的提交习惯。