目前工作上遇到这样的问题
有 Project A 因为不同客户需求不同分出了
Project A'、Project B (Fork)，但 Project A 的更新又得 merge 进 A' 及 B
有点继承的感觉
但是实际上 Merge 的结果却不是我想的
示意图：
https://i.imgur.com/5tGuKIJ.jpg
请问这样的状况是有什么地方做错
或者是说这样的 case 分 branch 就好呢？

最好是可以模组化把general function包成library分成不同的project给不同客户 customer project只存客制化的东西 general function都放回library然后用引用library的版本控制功能推进

repo 的内容是 web service但是客制的部份大都是另外新增的所以想说是不是可以有继承 A 的方法

善用分支是非常推荐的作法

主要用 Gitlab 进行，刚刚有测试这样的状况在 Github是不能用的

推荐分project的原因是因为最后客户常会要加新功能到时候就会有A'', B', B''

rebase就好

Project A的修改都开 feature分支，feature 在合并到 A,A',B

建议拆project较好 谁知道客户会不会提出什么鬼需求

我之前的做法是一个mono repo project ,，A B 共用的部分会是共用的package ,，然后 A B 有自己的 package 做客制化的东西还有去引用共用的部分

除非你可以把共用核心抽出模组，客制功能做成 plugins否则两个 branch 就只会渐行渐远。但你要每次都人工 merge人工 check 每行 code 也不是不行

A档案应该有发生冲突吧？合并过程中是有指定use remote or use local 吗？

和 19 楼想法类似，这应该是从程式码的层次下手，不然之后如果有更多客制化呢？建议可以去研究一下 Clean Architecture / Configuration Management 这些东西。

我觉得你应该用config。不同案子吃不同config，其他程式码一样维持一套code就好Feature也可以做成feature toggle, 然后吃config决定哪些feature要不要开

为什么不做在一起 再弄个权限控管 区分逻辑就好

现在的公司也有类似的问题，我们的情境是有两台不同device 上面要用一样的 android app，然后部分功能因应 device 的状况调整。目前是用两支branch 去做，有新增功能的话就 cherry-pick 过去。

这个基本上最后都是业务问题不是技术问题，上面挡不住什么神奇需求都接，你怎么设计都没用

推楼上

应该由程式码架构去着手，你这个做法会常常冲突，后续的人也很难维护

谢谢各位的回复目前我应该会用 config 的方式去设定然后再重新 fork核心部份仰赖 ProjectA 更新其他客制就 call ProjectA 的功能再加上要改的东西如果是 project A 的环境变量相关或功能就用 config处理真的感谢大家提供这么多意见

rebase

最后还是选fork,好奇不使用branch 的原因是?

直接开成新repo阿

开分支阿，顶多你推到不同的 remote

我比较好奇图中为何做了merge后A file还是A file，不是应该变成A与A’ merge file

我觉得thumbe31949你们需要的应该是dynamic feature或设定不同的buildTypes并设定sourceSet来做

上下游剪patch也行吧

fork 的原因我觉得用起来和 branch 一样但是在不同的 repo 的感觉因为平时的 branch 就有很多大家各自开发的项目，所以就比较没有考虑还是大家有其他的建议(?

同p大疑问 为何merge之后不是变A跟A’的merge file

A' 是对A做修改 至于说为什么结果这样我可能需要看 Gitlab 设定才知道我也很困惑，因为他和我想的不一样

可能你不知道branch 可以用'/'来分群组不过采用fork 也不是不行,只是merge时是用push/pull

什么 居然有 / 分群?!另外图的问题发现是 Gitlab 在 conflict 的时候 Preview 的 Bug... 害我误会了

让code可以吃configuration，不要直接分两版code

git patch