程序版本控制问题，一套程序跑上百家医院如何做好版本控制

假设最极端的情况：你的功能有 100 个，但是每个功能都可能用到 100 个医院的不同特性，这个时候实际上就是 10000 个功能。
这种规模的系统肯定是没法管理代码的。
于是折中的方法就是提取出有共性的 80 个功能，这些功能针对 100 个医院使用同样的代码。而剩下的还是有 2000 个....
但是功能的总数量下降到 2080 个，这是一个极大的进步了。
再继续用上面的方法。使得功能下降到可以接受进行版本管理的程度，然后加入开关。但是如果你这套系统最终有 200 个开关，实际上也是一场噩梦。
其实这套办法完全取决于你的系统有多少个功能.......我感觉开源软件其实就是这么干的。开源项目最大的优点是有几乎无限的开发资源...所以最后什么功能需要接受就成了一个最重要的事情。
我也是搞类似的系统的，目前确实没啥好办法。

跟我 2 年前做过的项目一样。。。我是用的 #7 楼的做法

这个问题非常常见，很头疼，推荐代码用同一套，功能通过配置来启用和关闭，但是当遇到冲突的时候就需要多考虑下。

his 实施，只能说做开关就方便。

医院的个性化流程是因为软件话语权不够强大导致的。

100 个医院 100 个需求，但是梳理标准化流程，
用标准化流程来作为主线，这部分尽量不改。
弥补的确符合逻辑的功能做成开关。
没一个开关要写清楚，这个开是干什么的关是干什么的即可。

每个功能都是插件，
每个插件自己维护一个版本控制，
每个客户提供一个插件配置文件

跟我说类似，但不是医院。

我们是一套代码多套配置文件，优点是维护方便点，缺点是代码量庞大，构建耗时，安装包大，启动耗时，因为它相当多个项目的并集。

用班本控制来切换医院？灾难的设计啊。

直接上 github-flow 啊。一个医院 fork 一个 repository

子模块单独全部独立出来，然后 N 个医院 N 个仓库，git subModule 集成？

模块化，不过最怕某个模块的功能，必须修改核心代码，这时候核心代码可以加开关，但是如果这种模块多了也是灾难

插件化（框架化）
写测试

可能有帮助

要 fork 也是 fork 模块，不要 fork 分支。fork 模块就是将模块代码复制一份，放到同一个分支里。
fork 模块，有重复代码也没关系，遇到需要修复的，也是修改同一个分支上的不同的文件，而不是多个分支。
后面时间充裕了，可以慢慢合并重复的模块。这个需要一开始就有完善的测试，不然没法保证重构之后还能正常运作。
当然，考虑到很多公司甚至测试都不写的，那可能就会选择 fork 分支，那就后果自负了。

之前微软不是有员工说 office 里有一大堆特性开关（ Gate ），每次修改（加功能，修 bug ）都要有开关可以控制。。。然后当然就是随之而来的一堆测试。。。

提供标准的能力和扩展点

感觉不是版本控制的问题，而是功能开关的问题
还有就是可以保证每个医院的某个功能是相同的，而没有各自定制话的东西？

上面都说的很好，模块化。但是祖传代码怎么模块化呢？ 工期在那里排着，只好 fork 分支然后改了。
后面多个分支需求不同，代码差异化越来越严重。感觉就像一辆失去控制的火车，只能眼睁睁看它走向深渊

你们公司没那么大能力同时维护多个 oem 的多历史版本，那就开成多项目吧。

最近也遇到了类似的问题。目前是靠开多个 feature 分支启动多个服务来解决，等测试完成后再分支合并回主分支。至于楼主你的不存在最终统一的版本。要不就用七楼的方法，要不就每个医院建一个仓库，把基本功能分出来一个基本仓库，新增的差异部分写在各自的仓库。

上百家医院，完了还是您这种情况......

这种问题十家八家的，模块化+模块控制可以解决。
Base 框架所有医院共享一个，完了开发标准的 1-4 模块，互不冲突的功能都在标准模块实现，差别从配置文件解决。
完了分支出来 3-C，1-D，3-D，4-D 解决模块间冲突。

如果这个架构扩展成几十家医院，可以考虑按划分二级分支，差别从配置文件解决。
比如北京市同一个医院对接医保系统的各个接口（医保卡认证、报销、查询其他医院用药记录）基本相同。
比如北京统一挂号平台（网上预约号）在北京所有医院适用。
比如北京京医通系统（挂号、缴费、检验单查询）在北京有接近二十家医院了。

问题是如果是共性不多的上百家医院，如果又不能引导需求的话。
我怕最后会出来几十个模块分支，继续 nightmare......

刚才有个小错误：
比如北京市所有的医院对接北京市医保系统的各个接口（医保卡认证、报销、查询其他医院用药记录）基本相同。

另外如果再不行，我觉得需要考虑微软 office 组的某些牛人了。牛到系统里做个大改动，一次改上千个文件完了系统还能 PASS 测试那种。