github有没有办法前后端分两个项目，前端代码软连接到后端文件夹中? 第1页

可以，请查看 git submodule 命令的帮助或教学，了解一下就能用了。但如果你同时控制两边的代码，强烈不建议使用 git submodule，因为后继问题非常坑，建议从一开始就做成 monorepo。

给你一个非常具体的例子，我的个人网站的源代码使用 submodule 连接 Bootstrap。

你可以看到我有一个叫做 bootstrap 的「目录」，在本地使用时真的如同一个目录一样，但本质上它只是一个指针，它指向另外一个 repo 并指定特定的 commit。

我这样做是因为没有选择，我不控制 Bootstrap 的 repo，但是我要直接引用 Bootstrap 编译之前的 scss 文件，在它上面叠加我的 scss，再一起编译输出我需要的 css。我不能直接使用 Bootstrap 编译输出的 css。

使用 submodule 最坑人的地方是依赖管理。之所以使用 submodule，肯定是两个 repo 存在依赖关系，甚至是多个 repo 之间存在复杂的依赖关系。使用 submodule 时，所有这些依赖都无法获得自动升级，因为指针指向哪个 commit 必须手动管理。

例如说，A 依赖于 B，用 submodule 指向 B 的一个具体 commit。有一天 A 的一名开发者想要用 B 的新功能，发现当前指向的 commit 没有，决定自行升级。他把 submodule 指向了 B 的 master，接着编译不过，因为 B 也在开发中，master 是坏的。他把 submodule 指向 B 最后一个发布版本的 tag，结果发现跟 A 不兼容。于是他开始摸索 B 到底哪个 commit 能给 A 用同时还有新功能，很可能不存在这样一个 commit。

事情发展到这一步，这名开发者觉得还不如把 B 发布到语言对应的包管理平台（例如 Node 对应 NPM），那 A 直接把 B 发布的稳定版本引用过来就可以了，而且还能用 SemVer 或其它方法限定 A 接受的 B 版本范围。这时候 submodule 就可以删掉了。（如果你要做一套基于 submodule 的依赖管理系统，那你就在发明一个新的包管理平台。）

然而这名开发者仍然很不爽。怎么你们维护 B 的团队做着做着就搞到跟 A 不兼容了吗？B 团队说，我们也不知道你们 A 团队在用啊，我们的测试一直能通过，你们的测试也一直能通过（因为没尝试升级 B 的版本），谁知道呢？这个问题的解决办法就是 monorepo。

当 A 和 B 都在一个 repo 里，B 团队开发时如果最新版本跟 A 不兼容，那 CI/CD 能直接通过编译和测试发现这个问题，然后阻止这个 commit 进入 master。在大公司里面，往往不止 A 和 B，还有数量众多的其它依赖关系，这是保证它们更新时保持互相兼容的方法。