现在，我的后端是一个经过良好模块化的目录结构，并且是RESTful API服务器。 我正在使用Hapi。
我面临的问题是我需要创建另一个后端项目，并且我想重用两个项目之间的所有通用功能，我想重用相同的代码库，相同的支架。
我有两种解决方案：
为新项目创建一个单独的git存储库，然后复制目录结构。 这种方法的主要问题是我正在复制代码。 如果需要修改此通用代码库，则需要修改2个项目，这是维护的噩梦。
对两个项目使用相同的git存储库。 幸运的是，Hapi具有连接的概念。 每个连接都绑定到不同的套接字，并具有自己的路由和内容，因此为其他服务器配置不同的连接非常容易。 在启动过程中，我可以选择要使用的连接，方法与此类似：
\n $ NODE_ENV =开发节点server.js-连接移动 \n $ NODE_ENV =开发节点server.js-连接Web\n
这是实现目标的最干净，最优雅的方法，但是它对我来说是一个重大缺陷，git flow，因为我不是该领域的专家。 我需要维护3个分支： base ， mobile和web 。 根据您所在的分支，您会看到不同的文件。 例如：
\n 。 \n ├─底座 \n │└─common.js \n ├─手机 \n │└─file1.js \n web─网页\n └─file2.js\n
如果当前分支是mobile ，则将看到base目录和mobile目录。
如果当前分支是web ，则将看到base目录和web目录。
如果当前分支是base ，则将看到base目录。
从软件版本控制的角度来看，这可以接受吗？ 部署到生产环境时，我只是将要上传的分支推送到远程分支上，然后在远程服务器上签出该分支并启动服务器。 例如：
要启动移动服务器：
本地
\n $ git push生产服务器移动\n
生产服务器
\n $ git checkout移动\n $ NODE_ENV =生产节点server.js-连接移动\n
要启动Web服务器：
本地
\n $ git push生产服务器网络\n
生产服务器
\n $ git checkout网站\n $ NODE_ENV =生产节点server.js-连接Web\n
到现在为止还挺好。 现在假设我需要修改基础并将更改应用于mobile和web分支。 我一直在阅读本文， 合并与重新设置基础并进行一些测试，而且我在SourceTree中看到重新构建正是我所需要的。 从视觉上讲，它更清洁，从概念上讲也可以，将base重新部署到mobile然后通过web将其更新为最新的base更改。
通过这种方法，没有master分支，而是有一个base分支，并且mobile和web 从未合并到base 。
你怎么看？ 只要所有团队成员都遵守规则，我就喜欢第二种方法。 我将负责审查对远程存储库的所有拉取请求，以便可以确认所有更改都可以。