Laravel 5 可重复使用的项目

Question

在为一个项目构建一个包之后，我们意识到按照

做我们需要实现的事情存在一些问题

也许我应该解释一下我的目标，有人可以建议前进的方向。

我们构建了一个 Laravel 5 应用程序，现在需要 "re-used"。

我们必须修改 Laravel 并实施 Eloquent 类型基础模型，因为我们的数据源实际上是 C# Web 服务。在对数据库进行调用时，我们拦截它并对 SOAP 进行 "API" 调用。

主要区别在于 CSS，可能有一些 JS 和内容，但所有 routes/controllers/models 在所有项目中都将保持不变。大多数配置来自端点。

最初我们考虑为每个站点的样式创建多个资产存储库，并有一个基础存储库，这是包含的核心 Laravel 项目。这似乎变得相当复杂，因为由于分支和多目录问题，我们不能简单地在一个回购中拥有一个回购。

然后我们开始尝试将 "core" 构建为 Laravel 包的想法，但我们似乎经常碰壁。最新的问题是在包中包含模型。对于要调用的模型，我们使用根项目 config/composer 来访问这些模型，而不仅仅是服务提供者。感觉这个包正在变得与项目配置紧密耦合。

有没有更好的方法来实现我们正在努力实现的目标？

编辑：

我忘记了 1 个 repo 上的多分支解决方案，但在功能开发方面这会不会变得很糟糕？示例：

master (core with releases that get pulled into _site*)
dev (master dev)
feedback-form (eg. master branch feature)
_site1 (root site with releases)
_site1-dev (_site1 dev)
_site1-reskin (eg. _site1 feature)
_site2 (root site with releases)
_site3 (root site with releases)

这会在开发人员手中留下相当多的破坏性合并能力吗？使用拉取请求进行读取访问可能是解决此问题的方法？

Answer 1

所以经过一些研发，现在最好的解决方案似乎是拥有 1 个具有多个分支的回购协议。开发人员具有读取权限，并让每个开发人员创建自己的分支。开发人员创建拉取请求并通过 "upstream" 远程同步到父仓库，开发人员通过其他远程同步彼此的分支。

看起来有点笨拙，但可能 "cleanest" 选项。

Laravel 5 可重复使用的项目

Laravel 5 re-usable project

php

git

laravel

laravel-5

package-development