前言
最近跟一些做策略研发的朋友沟通,发现不是技术背景的量化研究员,大部分都不会进行源码版本管理。最常见的场景就是每次有大的修改都把原来的代码重命名一下备份,然后再新建一个带不同标记的源码文件进行修改和测试。甚至还有一位朋友遭遇到交易服务器挂掉,导致最新版本的策略源码丢失的这种极端情况。
遇到这样的朋友,笔者一般都会极力安利一下版本管理的好处。正好最近准备帮朋友整理一下版本管理相关的一些东西,也就分享给大家,希望能对各位有所帮助。
版本管理简介
版本管理的基本概念
相信技术背景的读者对版本管理都很熟悉,本文这里还是简单介绍一下。版本管理就是对同一产品或系统进行局部修改所产生的产品或系统的系列变更情况进行记录、跟踪、维护和控制的过程。
版本管理的优点
- 源码集中管理,可以从不同设备同步最新的源码
- 源码每次修改都会被记录,随时可以进行回溯和跟踪
- 除了代码中的注释,提交源码时的备注,可以帮助开发人员从整体上了解某次修改的主要内容
- 部分版本管理工具还提供丰富的分支管理工具,十分方便
版本管理的必要性
- 对于稍微复杂一点的项目,不可能针对每个源文件进行单独的备份管理
- 源码存放在本地,很难支持多设备协同作业
- 源码同时存在于本地和版本库中,相当于有了多点备份,除非版本库所在设备和本地设备同时不可逆的损坏,不然就不可能出现源码丢失的情况
- 多人协作也需要依赖版本管理
版本日志截图
代码对比截图
代码追溯截图
使用版本管理
前面大致介绍了一下版本管理的一些特点,要建立版本库,选择一个合适的版本管理工具,也是非常重要的。
版本管理工具经历了不同时期流行的不同工具,而时下最流行的版本管理工具当为Git和SVN。Git
相对SVN
来说更灵活,支持本地提交,同时也能更好的管理分支,所以受到整个行业的追捧。
接下来本文将要介绍的三种构建版本库的方法,都是基于Git的。
利用代码托管平台管理源码
当下互联网有很多代码托管平台,这些平台一方面提供基础的版本管理的功能,同时还是开源库汇集的地方。
github
github是国外最流行的代码托管平台之一。主要面向开源及私有软件提供代码托管服务,只支持Git作为版本管理工具。现已被微软收购。优势
- 汇集了大量的开源软件,其中不乏知名开源项目
- 用户群巨大,国内国外都有大量的用户
- 除了开源项目,也支持私有库(最多3位协作人)
- 国外知识产权保护较好,源码的安全性相对有保障一些
劣势
- 因为国内网络的特殊性,
github
服务器在美国,国内访问速度受限严重 - 私有库只支持最多3人协作
- 因为国内网络的特殊性,
成本
- 个人使用直接成本为0
- 为了可以流畅的访问,可能需要购买
VPN
gitee
gitee是开源中国(OSChina)推出的一个代码托管平台。基本功能和github
基本一致,支持的版本管理工具还有SVN
。优势
- 国内服务器,国内访问速度快
- 支持直接从
github
同步开源项目,相当于针对github
搭建了VPN
劣势
- 国际认可度不够,只能在国内开源圈使用
- 私有库只支持最多5人协作
利用软件自建代码托管平台
量化策略的源码,相比软件源码更关注源码的安全性问题。有很多同行在管理策略源码的时候,都会担心自己策略源码泄露的问题。针对这样的顾虑,笔者推荐这些朋友可以考虑自建一个代码托管平台。
相比在线的代码托管平台,自建托管平台的优势是明显的:
- 绝对私有
- 完全可控
- 协作人数不受限
- 服务配置更灵活
不过,这样的方式还是有一些劣势:
- 需要自备服务器,如果是租云机,成本至少上千一年
- 引入技术栈太多,大多数量化研究员并不能很好地运用
但是对于一些已经有设备投入的朋友,这也是一个非常不错的选择。如果有朋友需要采用这种方式搭建自己的版本管理的话,笔者目前在公司内采用的是Gitblit进行代码管理,可以了解一下。
利用云盘搭建本地托管平台
前面介绍的两种方法,都是常规的方法,要不然是安全性存疑,要不然是成本太高,还需要引入额外的技术栈。笔者今天着重想介绍的方案是第三种方案:利用云盘搭建本地托管平台。
基本原理
这种方法有两个必要条件:SVN
和Git
都支持基于本地文件系统的版本库,简单来说就是版本库可以建在本地的一个文件夹中- 云盘的实时同步功能,笔者使用的是
360云盘
,同类的产品有坚果云
等
基于以上两个必要条件,就可以通过在云盘映射到本地的文件夹下,新建一个专用的文件夹,在此文件件建立一个本地的版本库(
SVN
、Git
都可以),在使用的时候,只需要将版本库映射为云盘的本地路径即可。搭建流程
口说无凭,下面笔者以自己库为例,给大家展示一下搭建的流程。- 先购买支持同步的云盘(请注意容量是否足够)
- 安装云盘同步软件,并映射到本地目录
- 新建一个
SourceGit
目录,并 利用Git
在SourceGit
创建一个纯版本库
- 新建一个工作目录,并
clone
刚才建立的版本库
- 在工作目录新建一个
readme.md
,并随便写一些内容
- 提交
readme.md
到本地版本库中(WorkDir
)
- 将代码推送到远程版本库中(云盘中的
SourceGit
目录)
以上就是笔者重点推荐的方案,这种方案除了提供了一种完整的源码管理方式以外,最重要的一点,可能也是诸多量化从业人员关注的一点就是,源码的私密性和安全性有绝对的保障。原因如下:
- 云盘都是个人使用,很难外泄
- 源码推送到远程版本库(即云盘中)以后,都是二进制形式存储的
- 除非有人很清楚的知道用户使用云盘的方式以及云盘中某个目录的文件到底是什么文件,不然一般情况下,即使拿到这些二进制文件也是没有用的
结束语
相信通过本文的介绍,各位读者对于如何管理自己的策略源码应该有了一个大致的了解了。因为时间有限,本文没有展开各种工具的具体用法。如果有读者对笔者推荐的方案有兴趣,想要尝试的话,有疑问可以再私信笔者了解具体做法。
WonderTrader旨在给各位量化从业人员提供更好的轮子,将技术相关的东西都封装在平台中,力求给策略研发带来更好的策略开发体验。
随着WonderTrader逐渐被更多人了解,有不少朋友对WonderTrader的架构设计和源码表现出非常浓厚的兴趣,想要深入地了解一下WonderTrader的内部代码细节。也给笔者提出了一些希望知道架构细节的想法。笔者思前想后了一段时间,决定在之后的几个星期,发布一个系列文章,主要就是介绍WonderTrader的一些设计细节。文章内容可能有点偏技术,希望感兴趣的朋友届时多捧场。
最后再安利一下WonderTrader
WonderTrader的github
地址:https://github.com/wondertrad...
WonderTrader官网地址:https://wondertrader.github.io
wtpy的github
地址:https://github.com/wondertrad...
市场有风险,投资需谨慎。以上陈述仅作为对于历史事件的回顾,不代表对未来的观点,同时不作为任何投资建议。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。