贡献导引

贡献导引

Bug 报告

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

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

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

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

核心开发讨论

你可以在 Laravel 创意 议题板 中针对现有的 Laravel 行为提出新的功能或改进。如果你提出了一个新功能,我们希望你会乐于实现一些至少能够完成该功能所需的必要代码。

有关 bugs、新特性还有现存特性的实现的讨论在 Laravel Discord server#internals 频道进行。Laravel 的维护者 Taylor Otwell 通常在工作日的上午 8 点到下午 5 点(UTC-06:00 或 America/Chicago)出现在该频道中,并在其他时间偶尔出现在该频道中。

选择哪个分支?

所有 bug 修复都应该发送到最新的稳定分支或 当前的 LTS 分支。除非修复了仅在即将发布的版本中存在的功能,否则永远不应将 bug 修复发送到 master 分支。

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

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

如果你不确定你的功能是重大功能还是次要功能,你可以在 Laravel Discord server#internals 频道询问 Taylor Otwell。

编译资源

如果要提交的更改会影响已编译的文件,例如在 laravel/laravel 仓库中 resources/sass 或者 resources/js 目录下的大部分文件,请不要提交已编译的文件。由于这类文件尺寸过大,维护者审查他们不太实际。这会被利用来作为往 Laravel 里注入恶意代码的一种方式。为了预防性地阻止这种情况发生,Laravel 的维护者将生成并提交所有编译文件。

安全漏洞

如果你发现 Laravel 中存在安全漏洞,请发送电子邮件至 Taylor Otwell,电子邮件地址为 taylor@laravel.com,所有安全漏洞都将得到及时解决。

编码风格

Laravel 遵循 PSR-2 编码规范和 PSR-4 自动加载规范。

PHPDoc

以下是正确写法的 Laravel 文档注释。请注意,@param 属性后跟两个空格、参数类型、两个空格,最后是变量名称:

/**
 * 在容器中注册绑定。
 *
 * @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 存储库中。这使得我们更多的关注贡献的内容而不是代码风格。

本文章首发在 LearnKu.com 网站上。
上一篇 下一篇
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
贡献者:4
讨论数量: 0
发起讨论 只看当前版本


暂无话题~