前言
最近跟一些做策略研发的敌人沟通,发现不是技术背景的量化研究员,大部分都不会进行源码版本治理。最常见的场景就是每次有大的批改都把原来的代码重命名一下备份,而后再新建一个带不同标记的源码文件进行批改和测试。甚至还有一位敌人遭逢到交易服务器挂掉,导致最新版本的策略源码失落的这种极其状况。
遇到这样的敌人,笔者个别都会竭力安利一下版本治理的益处。正好最近筹备帮敌人整顿一下版本治理相干的一些货色,也就分享给大家,心愿能对各位有所帮忙。
版本治理简介
版本治理的基本概念
置信技术背景的读者对版本治理都很相熟,本文这里还是简略介绍一下。版本治理就是对同一产品或零碎进行部分批改所产生的产品或零碎的系列变更状况进行记录、跟踪、保护和管制的过程。
版本治理的长处
- 源码集中管理,能够从不同设施同步最新的源码
- 源码每次批改都会被记录,随时能够进行回溯和跟踪
- 除了代码中的正文,提交源码时的备注,能够帮忙开发人员从整体上理解某次批改的次要内容
- 局部版本管理工具还提供丰盛的分支管理工具,非常不便
版本治理的必要性
- 对于略微简单一点的我的项目,不可能针对每个源文件进行独自的备份治理
- 源码寄存在本地,很难反对多设施协同作业
- 源码同时存在于本地和版本库中,相当于有了多点备份,除非版本库所在设施和本地设施同时不可逆的损坏,不然就不可能呈现源码失落的状况
- 多人合作也须要依赖版本治理
版本日志截图
代码比照截图
代码追溯截图
应用版本治理
后面大抵介绍了一下版本治理的一些特点,要建设版本库,抉择一个适合的版本管理工具,也是十分重要的。
版本管理工具经验了不同期间风行的不同工具,而时下最风行的版本管理工具当为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...
市场有危险,投资需谨慎。以上陈说仅作为对于历史事件的回顾,不代表对将来的观点,同时不作为任何投资倡议。