小弟 PHPER 一枚,求教下 api 如何做版本控制比较好?
目前我采用的方法是通过继承,目录结构如下:
modules
usercenter (模块名)
v1 (版本目录)
v2
v3
....
item
v1
v2
v3
...
URL 示例:/v2/usercenter/xxx 会访问到 usercener 下面的 xxx 方法, v2 里面可以配置继承自哪一个版本,如果配置了 v1 会全部继承过来,然后 v2 做相应的重写即可
这是小弟打算新项目这么只做,现在未重构前的项目是这样的,目录结构和上面一样, v1 和 v2 是不同的分支,所以当 v1 改动一个地方后要 merge 到 v2 ,还要 merge 到 v3...
但是感觉都不太好啊,想请教下各位朋友是怎么做的哇?感谢每一个回复的小伙伴
1
msg7086 2015-09-10 14:47:32 +08:00
你都继承了为啥还要 merge ?不是直接会在子类里生效么?
这个目录结构看着没啥问题啊。 |
2
xing393939 2015-09-10 14:49:34 +08:00
为啥要用 merge , 2 个不同的版本应该差别很大了吧,如果差别不大就直接再原版本上做兼容,不一定非要弄出 v1 v2 v3
|
5
cxbig 2015-09-10 14:56:50 +08:00
听楼主描述,应该是你们的版本间全是独立的,没有用到继承,做一个父类就好,把通用的方法、成员都放进去
可以是: v1 <- abstract v2 <- abstract 或者是: v1 <- abstract v2 <- v1 (注,这里的 abstract 是逻辑上的父类,不是 abstract class ) 有特殊用法的子类可以改写相关方法 method 和 成员 property |
6
cxbig 2015-09-10 15:03:36 +08:00
至于 vcs ,看上去用 git 的可能性很大,给个建议:
api |-v1 |-v2 \-v2 在 abstract 里改了以后提交到 branch:api ,然后每个分支做 merge from api api-\ \----\-v1 \----\-v2 \----\-v3 不太确定你的“感觉都不太好”是不是说这样做 git 的 commit 结构看上去很乱 如果是,这属于 OCD ,得治,药不能停 |
7
that24 OP @xing393939 感谢回复, merge 是因为两个项目不同,当 V1 里面的某一个方法和 V2 里面相同时,如果这个方法出 BUG 了,你不可能去改两个地方吧,所以就改 V1 然后 merge 到 V2 ,不一定是有大改动才上新版本吧,不好处理兼容的也得上新版本,比如我们的情况:我们的 api 供 pc 和 app 端使用,现在 pc 端的商品要加仓库的功能,购物车会有调整,如果做兼容会降低代码的可维护性,感觉反而整得有点乱,所以我们起了 V2 分支版本项目,因为 app 无法及时升级,实际情况起新版本的情况还是挺多的
|