1

在为一个项目构建了一个包之后，我们意识到按照Laravel 5 包开发清晰度做我们需要实现的事情存在一些问题

也许我宁愿解释我的目标，有人可以建议前进的方向。

我们已经构建了一个现在需要“重用”的 Laravel 5 应用程序。

我们不得不修改 Laravel 并实现一个 Eloquent 类型的基本模型，因为我们的数据源实际上是 C# Web 服务。此时，将对数据库进行调用，我们拦截它并对 SOAP 进行“API”调用。

主要区别在于 CSS，可能是一些 JS 和内容，但所有的路由/控制器/模型在所有项目中都将保持不变。大多数配置来自端点。

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

然后我们开始尝试将“核心”构建为 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)

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

4

1 回答 1

0

因此，经过一些研发之后，现在最好的解决方案似乎是拥有 1 个带有多个分支的 repo。开发人员具有读取权限，并且每个开发人员都可以创建自己的分叉。开发人员创建拉取请求并通过“上游”远程同步到父仓库，开发人员通过其他远程同步彼此的分叉。

似乎有点笨拙，但可能是“最干净”的选择。

于 2016-04-01T07:31:29.877 回答