目前工作上遇到這樣的問題
有 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