这是一个创建于 2378 天前的主题，其中的信息可能已经有所发展或是发生改变。
公司的分支管理比较乱，因为是多个项目，且甲方都很强势，个性化需求非常多。但是作为同一个产品其实也有蛮多共性化的东西。
开始打算是不同的项目在不同的分支上开发，不同的特性抽取出来之后做成开关之类的，去不同的甲方部署，就配置不同的开关。这些然后最后都要合并到主干上，形成统一的产品。
但是理想是丰满的，现实是骨感的。因为进度非常紧，全部抽取成产品模块，工期会拉长，一般求进度就先做了再说。搞到最后，只有一些小客户遵循这样的模式，大客户就在不同的分支上迭代了，有些产品经理觉得可以抽取到产品上的，又几乎是通过手工方式合并到主干上，版本现在搞的非常乱，又合不起来。
不知道针对这种同一个产品衍生粗来，但是每个客户又有很多定制化需求的版本控制，各位大佬有什么好一点的建议么？
 | 1 gz911122 2019-04-10 10:19:25 +08:00 不知道 没待过乙方 但是我从你的描述来看这种情况无解 |
 | 2 quickma 2019-04-10 10:34:33 +08:00 你们的人够多吗？够多就可以做成模块提取，不够多就分开吧，合不起来就合不起来吧 |
 | 3 sonyxperia 2019-04-10 10:40:05 +08:00 抽取部分人开发产品化的新项目；另外的人维护老版本；逐步推进升级到新版本 |
 | 4 wangkun2012324 2019-04-10 10:47:30 +08:00 严格实施组件化，各组件均区分版本，配置表管理各组件版本 |
 | 5 huahuajun9527 2019-04-10 10:52:38 +08:00 定制化都是手工活。。。 将功能拆分成模块，做一个能满足这类需求的框架，基于这个框架来做定制化开发。 不过之后肯定会遇到一些奇葩的甲方提出的奇葩需求，框架不能很好的实现这些功能，这时又会回到最初的样子。。。 |
 | 6 shawnde 2019-04-10 10:53:46 +08:00 git submodule |
 | 7 HangoX 2019-04-10 11:23:30 +08:00 因为定制化的问题，抽象是很难抽象的，建议直接建立一个母项目，然后所有人 fork 那个项目之后修改，需要共性的时候往母项目提 pull request 就好了 |
 | 8 wwwwzf 2019-04-10 11:24:26 +08:00 用 svn 好了 |
 | 9 shuang 2019-04-10 13:11:45 +08:00 关注，我们也有同样的问题 我们是优先通过开关控制 然后在主线上同一功能做多个不同版本，通过菜单权限控制 再不行了就开分支，目前也是很混乱 |
 | 10 passerbytiny 2019-04-10 13:32:07 +08:00 定制化开发，若甲方强势，则实质上每个甲方都是一个新的树，不再是分支。Git 对此无解。 |
 | 11 reus 2019-04-10 13:52:39 +08:00 产品不标准化，客户想要什么就有什么，这种产品是没办法快速复制，没办法做大的，收益抵不上成本 参考福特汽车早期的案例，标准化的流水线，可以击败那些效率低下的定制化工厂，不管你要什么，我就只有标准化的汽车。虽然没有定制，但成本低，可以卖得便宜 所以，定制化的，要么只靠几个大客户生存，要么就放弃定制化，要么就靠压榨员工不管质量 |
 | 12 daodao116 OP @wangkun2012324 现在大概也是想走这条路了。只能尝试一下。 |
 | 13 ben1024 2019-04-10 14:07:58 +08:00 要区分是 git 混乱，还是项目混乱 |
 | 14 danyi 2019-04-10 16:34:40 +08:00 关注，同样有这样的困扰。 |
 | 15 Fule 2019-04-10 16:59:14 +08:00 看起来楼主的情况，很难用分支处理。尤其是如果甲方 A 的功能甲方 B 也想要，但是甲方 C 不要。又或者甲方 D 和甲方 E 的需求根本就是矛盾的。这些情况分支似乎解决不了问题。我能想到的就是压根不要用分支，全都做在一起，纯利用开关来处理。当然，久而久之，开关关系错综复杂，一个小地方会被多个开关影响，理解起来也是非常混乱的。除非事先自己的规划和分析以及有份及时更新的文档，不过看楼主这情况，基本上也不太可能吧。总之，这个问题开发方面似乎没有什么“完美”的解决方法。。。 |
 | 16 sunocean 2019-04-10 17:10:15 +08:00 submodule +1 |
 | 18 haozibi 2019-04-10 18:32:43 +08:00 为什么不做成模块化的 |
 | 19 haato 2019-07-23 16:39:08 +08:00 国内很多传统行业软件都有这个问题吧。用户强势，需求变化快，用户对业务理解不深刻等等原因。感觉国内的这类情况，没有什么绝对好的方法，还是根据具体工期具体阶段选择合适的方法。个人感觉首先要分析用户需求，是业务痛点需求，还是某几个领导拍脑袋的想法？是需要长期维护的，还是做一两次就差不多的？由此决定哪些是核心业务功能，对于这些功能，一定要抽象出来模块化通用化，这事做得越早越有价值。其他模块，有人力就模块化，没人力就各干各的，以后再看情况处理。 |
 | 20 luckhzq 2020-12-01 09:43:03 +08:00 也是同样的问题，不知道大家有没有什么更好的方案 |
Select Language