项目由多个人员（公司）开发，但是不想让他们互相看到彼此的代码，除了手动合并代码该怎么办？

Question

公司的系统由多个公司共同开发，但是领导考虑到git做分支会导致代码泄露，想寻求一个方法可以让各公司可以自己提交发布自己开发的部分。目前的方法是各个公司将代码写完后，由我统一手动合并发布，这样参与的公司越来越多，会导致忙不过来或者无法及时发布的问题。目前是一个公司开发一个模块就是一个仓库，每次其他公司需要合并，我再去拉取他们最新的代码，然后把改动的目录给手动覆盖到主项目的文件夹中。

Answer 1

后端可以用微服务的方式，每个服务都是单独的Git仓库来迭代和部署。如果需要跨服务的数据就调对应服务的API就好了。

前端的话，我记得早几年火过一段时间的微前端的概念，也是类似后端的微服务概念，不同的功能模块单独维护和部署。主要就是看你如何把不同的模块聚合或者引入到项目当中了。

如果是一个功能模块会不同公司穿插开发的话，我就没有什么好的办法了，总不可能不给对方测试吧……还是说只提供给分支权限，然后以提交之后自动合并然后部署的方式？但是这样还是得手动解决冲突哇。

Answer 2

git submodule
将单独的模块独立出来. 用submodule 的形式发布到一个新仓库. 成员自行在新仓库中提交代码. 你只需要维护公共的就可以了.
如何进行发布呢.
利用git hook的特性. 自己在子仓库监听到对应的事件. 如果事件有更新. 则自动拉取代码就可以了.

Answer 3

这种问题不是在代码管理层面解决的，而是在系统架构层面解决的。举个例子，微信上跑了各种小程序，都用了同一套开发规范，但是并不各开发商都把微信的代码下载下来协同开发吧。

做应用系统也是一样的道理，如果应用系统的架构设计中考虑了第三方接入的“接口”那任何第三方都可以在按照规范开发的情况下，把程序接入大系统，不需要知道其他人的代码。框架层只需要发布一个规范，以及一套基础接口框架就可以了。

说起来简单，做起来难，不仅要有大局，还有很多细节需要处理。既然你们是买的一套框架，如果这套框架本身不支持插件式，可能要实现会有一些难度。

目标可以参考各种小程序框架，应用市场框架。技术可以参考微服务、微前端、插件化（比如 VSCode 就是经典中的经典）。具体该怎么做，就是具体情况具体分析了。

Answer 4

感觉这种代码管理方式有问题。 如果有代码合并，那么下一次fix bug或者开发新功能，肯定需要拉去全部代码，不然怎么基于最新代码做开发呢？

我提供一种思路，就是把网站的功能拆分成小模块，按照模块来创建仓库。不同公司维护不同的模块。模块间通过API约定好。

你只需要管理沟通好API，剩下的代码开发维护，由不同的公司维护不同的代码仓库。
如果出了bug，定位到模块，交由对应的公司去维护。

Answer 5

前端，
不同的人开发不同的页面 -> 微前端；
不同的人开发需求有交叉的功能 -> CDN、npm 包或 git submodule，总之代码加密好发出来。
不同的人开发同一个功能 -> 云主机；

如果楼主只是想解决手动合并的问题，那 gitlab pipeline、github actions、jenkins 这种都是合适的自动化工具

Answer 6

从描述上看，你的人工工作应该是可以自动化的。可以，写一个网页，让开发者自己填写相关信息，然后自动修改对应的文件。如果怕出错，可以加一个人工审核的步骤，审核通过再提交。

Answer 7

可以参考微前端的解决方案，在跳转到某一页面或路由时 加载的是另一个项目而不是本项目的一个路由。可以参考 阿里qiankun

Answer 8

后端微服务，前端微前端。

后端的话，其实也可以考按虑模块切分方式，将模块最终打成jar包依赖在主项目里面。

---

本文参与了SegmentFault 思否面试闯关挑战赛，欢迎正在阅读的你也加入。

Answer 9

感觉SVN就可以完美解决这个问题，为何要吊死在git这棵树上呢？

Answer 10

在这种情况下，您可以考虑使用Git的子模块功能。Git子模块允许您在一个仓库中引用另一个仓库。这样一来，每个公司都可以在自己的仓库中独立开发代码，而主项目仓库则包含指向各个子模块的引用。当需要更新子模块时，您只需更新主项目中子模块的引用即可。

以下是使用Git子模块的步骤：

在主项目仓库中添加子模块：

git submodule add <子模块仓库URL> <本地路径>

将<子模块仓库URL>替换为子模块对应的Git仓库URL，将<本地路径>替换为您希望在主项目中放置子模块的路径。

例如：

git submodule add https://github.com/CompanyA/moduleA.git modules/CompanyA

克隆主项目仓库时，使用--recurse-submodules参数以克隆所有子模块：

git clone --recurse-submodules <主项目仓库URL>

更新子模块：
要更新子模块，首先需要进入子模块目录，然后拉取并检出所需的分支或提交。例如：

cd modules/CompanyA
git fetch
git checkout <所需分支或提交>

回到主项目目录，将子模块更新提交：

cd ../..
git add modules/CompanyA
git commit -m "更新子模块CompanyA"

这样，您可以在主项目中管理各个公司的代码，而不需要手动合并。每个公司只能访问和修改其自己的仓库，不会看到其他公司的代码。

注意：使用子模块后，需要确保参与开发的人员了解子模块的概念和用法，以避免在使用过程中产生问题。
想接单可以联系我。

Answer 11

开发前，跟供应商或开发人员签署保密协议，不都这样吗？

Answer 12

微服务是你想要的。

Answer 13

第一、领导是“管理型”的吗？是的话让他滚，别插手技术。
第二、只看问题本身，要想完美解决，就只能通过修改顶层系统架构来实现，这事儿你一个人拍板没用。

Answer 14

？？
有那么复杂吗？
总部负责token，登录，菜单权限等等
子公司的平台必须依赖总公司的登录和菜单部分（用户信息控制在总部的接口）
然后自己去存 GIT 就好了，
总公司负责 Nginx 服务的配置，
让所有的平台代理后在同一个地址能被调用

GIT 我记得能搞库权限的控制的，
子公司或者项目组自己控子平台的权限就好了，
至于目录级别的权限？好像是 SVN 吧？

如果业务过小，切不出来 ...
那还要控制啥？
那么点东西就别折腾了