这是一个创建于 3380 天前的主题，其中的信息可能已经有所发展或是发生改变。
小弟 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...
但是感觉都不太好啊，想请教下各位朋友是怎么做的哇？感谢每一个回复的小伙伴
9 条回复 • 2015-09-10 15:27:04 +08:00
 |
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 无法及时升级，实际情况起新版本的情况还是挺多的
|
Select Language