我的后端现在它是一个模块化良好的目录结构，它是一个RESTful API服务器。我正在使用Hapi。
我面临的问题是我需要创建另一个后端项目，我想重用两个项目之间的所有常用功能，我想重用相同的代码库，相同的脚手架。
我有两个解决方案：
为新项目创建一个单独的git存储库，只需复制目录结构即可。这种方法的主要问题是我正在复制代码。如果我需要修改这个通用代码库，我需要修改2个项目，这是一个维护噩梦。
对两个项目使用相同的git存储库。幸运的是，Hapi有连接的概念。每个连接都绑定到一个不同的套接字，并有自己的路由和东西，因此很容易为另一个服务器配置不同的连接。在启动过程中，我可以选择使用哪种连接，这种方法类似于：
$ NODE_ENV=development node server.js --connection mobile $ NODE_ENV=development node server.js --connection web
这是实现我的目标最清洁和优雅的方式，但它对我来说有一个重大的不利因素，git flow，因为我不是这个领域的专家。我需要维护3个分支：base，mobile和web。根据您所在的分支，您会看到不同的文件。例如：
. ├─ base │ └─ common.js ├─ mobile │ └─ file1.js └─ web └─ file2.js
如果当前分支为mobile，您会看到base和mobile目录。
如果当前分支为web，您将看到base和web目录。
如果当前分支为base，您将看到base目录。
从软件版本控制的角度来看，这是可以接受的吗？在部署到生产时，我只需将我想上传的分支和远程服务器上的分支机构推送到该分支并启动服务器。例如：
启动移动服务器：
本地
$ git push production-server mobile
生产服务器
$ git checkout mobile $ NODE_ENV=production node server.js --connection mobile
启动网络服务器：
本地
$ git push production-server web
生产服务器
$ git checkout web $ NODE_ENV=production node server.js --connection web
到目前为止，这么好。现在假设我需要修改基础并将更改应用于分支mobile和web。我一直在阅读这篇文章，merge vs rebase并做了一些测试，我在SourceTree中看到，变形正是我所需要的。视觉上它更清晰，概念上没问题，将base重新定位到mobile和web只是将它们更新为最新的base更改。
使用此方法，没有master分支，而是base分支，而mobile和web 从不合并到{{1} }}