请教大家这样的项目应该要怎么做 git 管理

26 天前
 houshengzi

前提:手头上准备有一个项目 project 要开发,目前规划是会开发出一个基础版本,然后这版本上线后,基于该版本会按照不同的客户需求有一些差异不大的定制化修改,可能就会出现 project-A 、project-B 甚至是 C/D/E....等多个版本。

团队考虑了两种版本管理方式:

  1. 分支模式。 除了常见的 main/dev/release ,对于定制化的就从 main 拉出对应分支 project-A ... Z ,如果 A 有修改则拉出 feature 进行开发,开发测试完毕合回 project-A 里。 如果 main 有通用更新则按照情况从 main 合到 project-A ... Z ,同理如果 project-A 的一些功能验证过后按需也可以合回到 main 。

  2. fork 模式。 基础版本正常开发迭代,有定制的需要时则从基础版本 fork 出一个 project-A ,它可以方便地随时同步上游仓库的修改,project-A 有被用户验证过后的功能也可以向上游仓库发起 merge 请求合到基础版本中

个人感觉分支模式到时候如果真的出现很多 project-X 分支的时候,有可能分支之间合并就乱了,也会把 git 的记录搞得很花。

另外解决怎么安排测试也是一个大问题

大家对以上两种模式有什么看法或建议? 或者有更合理的管理模式也可以提出供我们参考

2489 次点击
所在节点    git
39 条回复
zhuisui
26 天前
对于 git 来说,你这两种模式没区别,都是 branch.
你说 fork 的时候是不是指 github 上的 repo 。这时候这两者的区别在于 repo 层面的管理,包括 org 、member 、permission 什么的。

你这种需求——拆出去、合回来,用 branch 管理是最合适的,设计好各种条件下如何建分支就好了。不要用什么 cherry-pick 甚至多项目。
newaccount
26 天前
1 分支模式
已经上线运行的东西
客户不给钱,公司没有升级的动力
公司想升级,客户未必愿意冒风险
基于这个理由,project-A 同步 main 这个需求不存在
dalaoshu25
26 天前
交付给客户的当然是 release 分支,里面可以有一些针对客户的定制,跟主线无关的。
貌似“定制化”也应该是从 release 分支再拉出 feature 乃至 hotfix 分支。这些定制有没有需要合并回主线,另外再评估。
angryfish
26 天前
从来没做过这种定制化需求的项目,很好奇怎么管理那么多不同公司需求版本的。
xingheng
26 天前
无脑 fork ,定制需求更新会很低,分开管理最好,分开了也可以合并基础版本的代码,不冲突。
flyPig9527
26 天前
@angryfish 各种 if 判断
flyPig9527
26 天前
@angryfish 说错了,这种很麻烦,各个分支切换要重新装依赖,同时开发多个定制分支就很蛋疼
liuliuliuliu
26 天前
是不是应该考虑做成功能开关?不同的客户,只是哪些功能打开关闭而已
Jonz
26 天前
我们应该算是分支模式。
我主要负责标准品的开发,也就是 feature 分支开发,然后本迭代完成下发后拉 release 分支。
特单部门的同事接到新的定制需求就会基于标准品最新的 release 分支拉个 release-xxx 需求的分支进行开发和发布。
不过有个前提是我们的特单理论上是不会直接升级到标准品的。遇到特别严重的问题就手动把代码改过去。
Sainnhepark
26 天前
可以考虑把部分定制化需求用配置文件控制,如果差异确实较大,可以考虑把公共的实现放到一个 common 库,然后构建的时候构建多个版本的程序
pangzipp
26 天前
有没有可能 main 作为基准。对外提供接口
然后定制好业务去聚合接口呢?
0x5c0f
26 天前
今天才整理的,你应该需要的是这个
bfdh
26 天前
不要拉分支,不同分支会越差越多,最后结果就是不同分支之间的修改完全没法同步/合并。
我现在是所有项目一个分支,每个项目有自己的配置目录,根据配置进行编译。
hzymyp
26 天前
之前是按照多个分支来管理的,后来发展成了近 30 个分支的树状结构,实在受不了又改成功能开关模式了
LemonNoCry
26 天前
可以用分支模式,可以用目录来区分

比如
标准版:dev/release/preview

客户 A: A/dev ,A/release ,A/preview
客户 B 以此类推

就是合并会比较繁琐

但是一般情况不会升级,只有客户反馈等等,比如标准版已经加了其他功能,客户 A 的版本还是老版本,没有特别一般不会进行升级,
PolarisY
26 天前
搜一下 gitflow ,基本是业内共识规范,可以在其基础上客制化。至于你提到的切换问题,可以 clone 多个本地库互不影响呀。
你应该基于权限考虑去设计这个规范。
HtPM
26 天前
巧了,我们公司目前就是用的你提到的第一种分支模式。有一个 master 分支作为公司的线上发布 Release 版本(作为里程碑),比如 OEM 厂商 1 需要定制一个功能,就基于 Master 分支新建另一个分支,比如名称取为:master-oem1 。目前已经 144 个分支了。这种模式下暂时也没什么大问题,不过偶尔需要合并大量的代码的时候会有点痛苦,不过基本上问题不大(因为我们是小公司[doge])
cnnblike
26 天前
搞一个门禁,把所有 master 上的 commit cherry-pick 到定制分支上
xavierchow
26 天前
2 楼 @newaccount 讲的很对,相信我,一旦定制化以后,你不会有机会 merge 回来了,不同客户的需求下,分支模式并不适合。
建议把基础版本作为一个 git template repo ,需要定开的话,直接 clone 出一个新的 repo 独自演化吧。
k9990009
26 天前
现在用的分支模式。客户的代码落后 N 个大版本了,除非不更新。实际上一些好用的功能和优化会,不同分支相互合并。太痛苦了。应该考虑模块化,插件化去做

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/1100745

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX