git submodule

這種問題不是在代碼管理層面解決的，而是在系統(tǒng)架構(gòu)層面解決的。舉個(gè)例子，微信上跑了各種小程序，都用了同一套開發(fā)規(guī)范，但是并不各開發(fā)商都把微信的代碼下載下來協(xié)同開發(fā)吧。

做應(yīng)用系統(tǒng)也是一樣的道理，如果應(yīng)用系統(tǒng)的架構(gòu)設(shè)計(jì)中考慮了第三方接入的“接口”那任何第三方都可以在按照規(guī)范開發(fā)的情況下，把程序接入大系統(tǒng)，不需要知道其他人的代碼。框架層只需要發(fā)布一個(gè)規(guī)范，以及一套基礎(chǔ)接口框架就可以了。

說起來簡單，做起來難，不僅要有大局，還有很多細(xì)節(jié)需要處理。既然你們是買的一套框架，如果這套框架本身不支持插件式，可能要實(shí)現(xiàn)會(huì)有一些難度。

目標(biāo)可以參考各種小程序框架，應(yīng)用市場框架。技術(shù)可以參考微服務(wù)、微前端、插件化（比如 VSCode 就是經(jīng)典中的經(jīng)典）。具體該怎么做，就是具體情況具體分析了。

感覺這種代碼管理方式有問題。 如果有代碼合并，那么下一次fix bug或者開發(fā)新功能，肯定需要拉去全部代碼，不然怎么基于最新代碼做開發(fā)呢？

我提供一種思路，就是把網(wǎng)站的功能拆分成小模塊，按照模塊來創(chuàng)建倉庫。不同公司維護(hù)不同的模塊。模塊間通過API約定好。

你只需要管理溝通好API，剩下的代碼開發(fā)維護(hù)，由不同的公司維護(hù)不同的代碼倉庫。
如果出了bug，定位到模塊，交由對應(yīng)的公司去維護(hù)。

前端，
不同的人開發(fā)不同的頁面 -> 微前端；
不同的人開發(fā)需求有交叉的功能 -> CDN、npm 包或 git submodule，總之代碼加密好發(fā)出來。
不同的人開發(fā)同一個(gè)功能 -> 云主機(jī)；

如果樓主只是想解決手動(dòng)合并的問題，那 gitlab pipeline、github actions、jenkins 這種都是合適的自動(dòng)化工具

從描述上看，你的人工工作應(yīng)該是可以自動(dòng)化的?？梢?，寫一個(gè)網(wǎng)頁，讓開發(fā)者自己填寫相關(guān)信息，然后自動(dòng)修改對應(yīng)的文件。如果怕出錯(cuò)，可以加一個(gè)人工審核的步驟，審核通過再提交。