[咨询] 关于 git 版本管理

[daodao116]

公司的分支管理比较乱，因为是多个项目，且甲方都很强势，个性化需求非常多。但是作为同一个产品其实也有蛮多共性化的东西。

开始打算是不同的项目在不同的分支上开发，不同的特性抽取出来之后做成开关之类的，去不同的甲方部署，就配置不同的开关。这些然后最后都要合并到主干上，形成统一的产品。

但是理想是丰满的，现实是骨感的。因为进度非常紧，全部抽取成产品模块，工期会拉长，一般求进度就先做了再说。搞到最后，只有一些小客户遵循这样的模式，大客户就在不同的分支上迭代了，有些产品经理觉得可以抽取到产品上的，又几乎是通过手工方式合并到主干上，版本现在搞的非常乱，又合不起来。

不知道针对这种同一个产品衍生粗来，但是每个客户又有很多定制化需求的版本控制，各位大佬有什么好一点的建议么？

[gz911122]

不知道 没待过乙方
但是我从你的描述来看这种情况无解

[x7395759]

你们的人够多吗？够多就可以做成模块提取，不够多就分开吧，合不起来就合不起来吧

[sonyxperia]

抽取部分人开发产品化的新项目；另外的人维护老版本；逐步推进升级到新版本

[wangkun2012324]

严格实施组件化，各组件均区分版本，配置表管理各组件版本

[huahuajun9527]

定制化都是手工活。。。
将功能拆分成模块，做一个能满足这类需求的框架，基于这个框架来做定制化开发。

不过之后肯定会遇到一些奇葩的甲方提出的奇葩需求，框架不能很好的实现这些功能，这时又会回到最初的样子。。。

[shawndev]

git submodule

[HangoX]

因为定制化的问题，抽象是很难抽象的，建议直接建立一个母项目，然后所有人 fork 那个项目之后修改，需要共性的时候往母项目提 pull request 就好了

[wwwwzf]

用 svn 好了

[shuang]

关注，我们也有同样的问题
我们是优先通过开关控制
然后在主线上同一功能做多个不同版本，通过菜单权限控制
再不行了就开分支，目前也是很混乱

[passerbytiny]

定制化开发，若甲方强势，则实质上每个甲方都是一个新的树，不再是分支。Git 对此无解。

[reus]

产品不标准化，客户想要什么就有什么，这种产品是没办法快速复制，没办法做大的，收益抵不上成本

参考福特汽车早期的案例，标准化的流水线，可以击败那些效率低下的定制化工厂，不管你要什么，我就只有标准化的汽车。虽然没有定制，但成本低，可以卖得便宜

所以，定制化的，要么只靠几个大客户生存，要么就放弃定制化，要么就靠压榨员工不管质量

[daodao116]

@wangkun2012324 现在大概也是想走这条路了。只能尝试一下。

[ben1024]

要区分是 git 混乱，还是项目混乱

[danyi]

关注，同样有这样的困扰。

[Fule]

看起来楼主的情况，很难用分支处理。尤其是如果甲方 A 的功能甲方 B 也想要，但是甲方 C 不要。又或者甲方 D 和甲方 E 的需求根本就是矛盾的。这些情况分支似乎解决不了问题。我能想到的就是压根不要用分支，全都做在一起，纯利用开关来处理。当然，久而久之，开关关系错综复杂，一个小地方会被多个开关影响，理解起来也是非常混乱的。除非事先自己的规划和分析以及有份及时更新的文档，不过看楼主这情况，基本上也不太可能吧。总之，这个问题开发方面似乎没有什么“完美”的解决方法。。。

[sunocean]

submodule +1

[daodao116]

@sunocean 我研究一下，谢谢。

[haozibi]

为什么不做成模块化的

[haato]

国内很多传统行业软件都有这个问题吧。用户强势，需求变化快，用户对业务理解不深刻等等原因。感觉国内的这类情况，没有什么绝对好的方法，还是根据具体工期具体阶段选择合适的方法。个人感觉首先要分析用户需求，是业务痛点需求，还是某几个领导拍脑袋的想法？是需要长期维护的，还是做一两次就差不多的？由此决定哪些是核心业务功能，对于这些功能，一定要抽象出来模块化通用化，这事做得越早越有价值。其他模块，有人力就模块化，没人力就各干各的，以后再看情况处理。

[luckhzq]

也是同样的问题，不知道大家有没有什么更好的方案