小弟 PHPER 一枚，求教下 api 如何做版本控制比较好？

[that24]

小弟 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...
但是感觉都不太好啊，想请教下各位朋友是怎么做的哇？感谢每一个回复的小伙伴

[msg7086]

你都继承了为啥还要 merge ？不是直接会在子类里生效么？
这个目录结构看着没啥问题啊。

[xing393939]

为啥要用 merge ， 2 个不同的版本应该差别很大了吧，如果差别不大就直接再原版本上做兼容，不一定非要弄出 v1 v2 v3

[that24]

@msg7086 感谢回复，继承是新项目打算这么做的， merge 是以前的项目，能说说你们现在是怎么做的么？

[msg7086]

@that24 我们？我们是谁？
现在我不写 API 也不写 PHP ……

[cxbig]

听楼主描述，应该是你们的版本间全是独立的，没有用到继承，做一个父类就好，把通用的方法、成员都放进去
可以是：
v1 <- abstract
v2 <- abstract
或者是：
v1 <- abstract
v2 <- v1
（注，这里的 abstract 是逻辑上的父类，不是 abstract class ）
有特殊用法的子类可以改写相关方法 method 和 成员 property

[cxbig]

至于 vcs ，看上去用 git 的可能性很大，给个建议：
api
|-v1
|-v2
\-v2
在 abstract 里改了以后提交到 branch:api ，然后每个分支做 merge from api
api-\
\----\-v1
\----\-v2
\----\-v3
不太确定你的“感觉都不太好”是不是说这样做 git 的 commit 结构看上去很乱
如果是，这属于 OCD ，得治，药不能停

[that24]

@xing393939 感谢回复， merge 是因为两个项目不同，当 V1 里面的某一个方法和 V2 里面相同时，如果这个方法出 BUG 了，你不可能去改两个地方吧，所以就改 V1 然后 merge 到 V2 ，不一定是有大改动才上新版本吧，不好处理兼容的也得上新版本，比如我们的情况：我们的 api 供 pc 和 app 端使用，现在 pc 端的商品要加仓库的功能，购物车会有调整，如果做兼容会降低代码的可维护性，感觉反而整得有点乱，所以我们起了 V2 分支版本项目，因为 app 无法及时升级，实际情况起新版本的情况还是挺多的

[msg7086]

@that24 提取公共逻辑，然后尽可能重用代码才是真的。
如果逻辑差异真的很大，那手改也不是不行啦。

[that24]

@cxbig 感谢回复，思考了很久，你这个方法挺好，我再琢磨琢磨。 3Q