不同的项目版本用 git 分支还是变量判断来管理？

This topic created in 1679 days ago, the information mentioned may be changed or developed.

公司的一个项目，有一个通用版本，对于不同客户基于这个通用版本要改一些东西

领导的想法：用变量判断，同一份代码方便维护

我的想法: 一个通用版本分支，其他版本各一个 git 分支，通用版本作为 base，每次通用版本加功能别的分支可以 rebase 上去

现在只有一家客户，领导用了变量判断，我觉得很脏，应该用分支管理，否则以后客户一多版本增加，一有差异功能都需要判断，分散在整个项目里很乱

想问一下大家都是怎么做的？

版本

分支

通用

变量

21 replies • 2021-10-19 02:22:39 +08:00

gaoli1992

Oct 18, 2021

我现在接手的项目之前的团队就是你这么做的，有一个 base 版本，然后会维护多个私有化版本

但是随着版本功能的推进就会发现，base 版本向私有化版本合并的工作量越来越大，后来交接到我们手上，更是由于工作量太大，就只要固定了私有化版本，放弃了更新。

当然也有之前团队也得就是屎山代码的原因。

AoEiuV020

Oct 18, 2021

我们是用分支，
不过有一点和你们的情况不一样，我们客户分支是有限维护，
只修 bug 或者客户定制的功能，不持续合并新功能，客户没提问题了这分支就不再更新了，

zoharSoul

Oct 18, 2021

我没做过这种工作, 建议不要干乙方, 趁早跑路. :P

如果要做的话我选择变量

dyxLike

Oct 18, 2021

定制化版本的功能特性到后面可能会和 base 版差距很大, 我们之前项目用的分支形式, 到最后就只修 bug 不更新了

del1214

Oct 18, 2021

不管是变量还是分支，都很难受，跑路才是正解

ntdll

Oct 18, 2021

还是和构建工具有一点关系，比如像 Android 这样的，Gradle 本身支持一定程度的变体构建，那么代码中做好一些抽象，我觉得比用变量判断和分支都方便。

如果非要这两种里面选择，还是看非通用版本预期的维护时间，时间长的话，通用版本 marge 到特定版本会非常痛苦，通用版本的新代码很难考虑到以前代码的兼容性。

NotFoundEgg

Oct 18, 2021

千万别用变量后面逻辑改动会越来越频繁需求会越来越奇怪不同业务的逻辑冲突变量根本加不上
而且万一以后客户量上去了再拆会更痛苦的

chenluo0429

Oct 18, 2021

选用分支，你可能会遇到一下情况：
1. 当你在通用分支的修改，分支 AB 可以直接合并；分支 C 完全无法合并，需要手动修改；分支 D 可以合并，但是功能不正常；分支 E 不需要合并。
2. 你的修改产生了一些 bug，你需要在 ABCDE 分支上分别修改，因为它们的代码存在差异，修改方案并不能完全通用，有些分支可能没有问题；
3. 不同分支之间的依赖渐渐有了差异，为了方便地切换工作，你的硬盘上每个分支都有了一个独立的项目文件夹，你需要打开 3 、4 个 IDE 来同时处理不同分支上的同一个问题
...

脏来自于对于客户需求的无底限妥协，无论你选择的是分支还是变量，最后都逃不过屎山的命运。

importcode

Oct 18, 2021

无论分支还是变量都逃不过，后续客户多了后差异越来越大，考虑一下通用模块做标准化，按功能添加逻辑判断而不是按客户，定制部分独立为可插拔模块单独维护

cs419

Oct 18, 2021

对项目 fork 进入维护模式
不加新功能只做缺陷维护

Vindroid

Oct 18, 2021

看客户需求都是买断版本制的，那就 branch，后期只做 bug 修复，不跟随 base 进版。如果客户的版本也是要随 base 进版，那还是变量控制吧，至少进版不会恶心到开发，测试量也不会增加太多，做好客制化的控制，代码上还是能接受的。另外核心功能是绝对不能变更的，只能扩展、新增，不能修改、删除。