缘起：由于之前公司资金的一些问题，无法继续经营下去，被迫离开了原来的公司，进入一个新的公司，发现周围的新同事有事没事就喜欢聊区块链，人工智能之类的，我觉得相互学习研究技术没毛病，但一定是在完成本职工作的前提，无论做哪一行工作都是一样。。。不多说了，出于公司服务端版本的一些问题，进而整理一些，以备不时之需。
开发一个项目的时候版本迭代基本上是一个星期一次,为了配合端进行了最简单的 版本控制(分文件请求地址的控制)后来发现到后面一次性要维护,3到5个版本而且真正上的逻辑差别都不大,只是为了做到配合端做好 版本控制,后来意识到这种方式在这种快速开发中是不可取得,在后面的了解和探索中发现了大小版本控制比较适合。
一.对于web服务端和App服务端要区别对待
对于web端实行同步更新,有且只有一个后端版本存在,与web同时上线迭代更新.例如：现在线上有一套web和后端版本,新的开发任务完成后,线上的版本进行下线, 新的版本进行上线。只需保证好代码备份回滚就好～
对于，App服务端来讲，版本控制要严格把控一下了，以下主要是对App服务端来讲。
二.小版本控制
对于小版本控制存在的意义在于在一次迭代中接口改动很小但是有个别接口有轻微的逻辑变化,比如:
(1)在下一个版本中有一个接口取消了不允许被访问了
(2)某个接口增加或者是删除了几个返回值
(3)某个接口增加了一点点逻辑
例: ?v=2.0.2 ?v=2.0.3 比如2.0.2请求的时候需要返回4个参数 而2.0.3只需要返回2个参数 在迭代升级中不需要重新开启一个项目而进行小版本控制会来的更快更好管理