贡献导引

Bug 报告

为了鼓励积极协作，Laravel 官方强烈鼓励你拉取请求，而不仅仅是提交 Bug 报告。「Bug 报告」也可以以包含失败测试的拉取请求的形式发送。

然而，如果你提交了一个 bug 报告，你的议题（issue）应该包括关于这个议题一个标题和一个清晰的描述。你还应该包含尽可能多的相关信息以及演示该议题的代码示例。Bug 报告的目的就是让你自己和他人能够轻松地复现 bug 并修复它。

谨记，bug 报告的创建是希望和你有同样问题的他人能够与你协作解决问题，不要指望 bug 报告能够自动查看任何活动或者其他人跳转自此来修复它。创建 bug 报告有助于帮助自己和其他人开始着手解决问题。

Laravel 源码托管在 GitHub 上，每个项目都有一些仓库：

支持问题

Laravel 的 GitHub 的 issue 功能不打算提供 Laravel 的帮助或支持。 相反，使用以下渠道之一:

核心发展讨论

您可以在 Laravel Ideas 发行委员会 提出新功能或对现有 Laravel 行为进行改进。如果您提出一项新功能，您得愿意至少完成该功能所需的一些代码。

关于 Bug，新功能以及现有功能的实现的非正式讨论在 Laravel Discord服务器 的渠道中进行。Laravel 的维护者 Taylor Otwell 通常在工作日的上午8点至下午5点（UTC-06：00或美国 / 芝加哥）出现在频道中，偶尔也会在其他时间出现在频道中。

哪个分支?

所有的 错误修复都应发送到最新的稳定分支或 当前的LTS分支 。除非将其修复的漏洞仅修复在即将发布的版本中，否则 永远不 应该将其发送给 master 分支。

与当前版本 完全向后兼容的次要 功能可能会发送到最新的稳定分支。

主要的 新功能应始终发送到包含即将发布的版本的 master 分支。

如果不确定您的功能是否合格，请在 Laravel Discord服务器 中询问 Taylor Otwell。

编译资产

如果您提交了修改，将会影响编译的文件。如大多数在 laravel/laravel 仓库的 resources/sass 或 resources/js，所以不要提交编译后的文件。由于它们的文件很大，因此维护人员实际上无法对其进行检查，这可能被利用作为向 Laravel 注入恶意代码的一种方式。为了防止这种情况，所有编译的文件都将由 Laravel 的维护人员生成和提交。

安全漏洞

如果您在 Laravel 中发现一个安全漏洞，请发送电子邮件至 Taylor Otwell 。所有安全漏洞将得到及时解决。

编码风格

Laravel 遵循 PSR-2 编码标准和 PSR-4 自动加载标准。

PHP文档

以下是有效的 Laravel 文档块示例。请注意，@param 后跟两个空格，再写参数类型，另外再跟两个空格，最后是变量名称：

/**
 * Register a binding with the container.
 *
 * @param  string|array  $abstract
 * @param  \Closure|string|null  $concrete
 * @param  bool  $shared
 * @return void
 *
 * @throws \Exception
 */
public function bind($abstract, $concrete = null, $shared = false)
{
    //
}

StyleCI

如果您的代码样式不完美，请不要担心！合并拉取请求后， StyleCI 将自动将所有样式修复程序合并到Laravel 仓库中。这使我们可以专注于贡献的内容而不是代码样式。

行为准则

Laravel 行为准则源自 Ruby 行为准则。任何违反行为准则的行为都可以报告给 Taylor Otwell（taylor@laravel.com）：

  • 参与者容忍相反的观点。
  • 参加者必须确保其语言和行动不受人身攻击和诋毁。
  • 在解释他人的言行时，参与者应始终保持善意。
  • 可以认为骚扰的行为是不能容忍的。

热门教程

最新教程