Để khuyến khích cho sự phát triển, Laravel rất khuyến khích bạn tạo các pull request, không chỉ là báo bug. "Báo bug" cũng có thể là một pull request được gửi dưới dạng là một bài test thất bại.
Tuy nhiên, nếu bạn muốn tạo một bug, thì bug của bạn nên chứa một tiêu đề và một mô tả rõ ràng về bug mà bạn gặp phải. Bạn cũng nên mô tả càng nhiều thông tin liên quan đến bug càng tốt và một code ví dụ để tạo ra bug đó. Mục tiêu của báo bug là giúp bạn dễ dàng - và những người khác - tái hiện lại bug đó và phát triển các bản sửa bug.
Hãy nhớ rằng, báo bug được tạo ra với hy vọng rằng những người khác có cùng vấn đề với bạn có thể cộng tác với nhau để cùng nhau sửa bug. Bạn đừng hy vọng rằng báo bug sẽ làm khởi động một quá trình sửa bug nào đó hoặc người khác sẽ nhảy vào để sửa giúp bạn. Tạo một bug để giúp chính bạn và những người khác, bắt đầu một quá trình sửa bug mà bạn đã báo cáo. Nếu bạn muốn trợ giúp, bạn có thể trợ giúp bằng cách sửa bất kỳ lỗi nào được liệt kê trong issue tracker của chúng tôi.
Mã nguồn của Laravel được quản lý trên GitHub và có các repository cho từng dự án của Laravel:
GitHub issue tracker của Laravel không nhằm mục đích cung cấp các trợ giúp hoặc hỗ trợ cho Laravel. Thay vào đó, hãy sử dụng một trong các kênh sau:
Bạn có thể đề xuất các tính năng mới hoặc các cải tiến về các hành động của Laravel trong Laravel Ideas issue board. Nếu bạn đề xuất một tính năng mới, vui lòng làm sẵn một số code cần thiết để hoàn thành tính năng này.
Kênh #internals
của Laravel Discord server sẽ thảo luận về các lỗi, tính năng mới và triển khai các tính năng hiện tại. Taylor Otwell, maintainer của Laravel, thường có mặt trong kênh này vào các ngày trong tuần từ 8 giờ sáng đến 5 giờ chiều (UTC-06:00 or America/Chicago) và xuất hiện thường xuyên trong kênh vào các thời điểm khác.
Tất cả các bản sửa lỗi phải được gửi đến branch ổn định mới nhất hoặc tới các branch LTS hiện tại. Các bản sửa lỗi sẽ không được gửi đến branch master
trừ khi chúng sửa các tính năng đã tồn tại trong bản phát hành sắp tới.
Các tính năng phụ có tương thích với bản phát hành hiện tại thì có thể được gửi đến branch ổn định mới nhất.
Các tính năng chính mới phải luôn được gửi đến branch master
, nơi chứa code của các bản phát hành sắp tới.
Nếu bạn không chắc chắn tính năng của bạn là chính hay là phụ, vui lòng hỏi Taylor Otwell trong kênh #internals
của Laravel Discord server.
Nếu bạn đang gửi một thay đổi sẽ ảnh hưởng đến các file đã được biên dịch, chẳng hạn như các file ở trong resources/sass
hoặc resources/js
của repository laravel/laravel
, thì đừng commit các file đã biên dịch trên. Bởi vì, trên thực tế, do kích thước của file đó quá lớn, nên chúng sẽ không thể được review bởi người quản lý. Và điều này cũng có thể bị khai thác như là một cách để đưa mã độc vào trong source code của Laravel. Để ngăn chặn điều này, tất cả các file đã biên dịch sẽ được tạo và commit bởi những người quản lý source Laravel.
Nếu bạn phát hiện ra lỗ hổng bảo mật trong Laravel, vui lòng gửi email đến Taylor Otwell theo địa chỉ [email protected]. Tất cả các lỗ hổng bảo mật sẽ được giải quyết kịp thời.
Laravel tuân theo tiêu chuẩn coding PSR-2 và tiêu chuẩn autoloading PSR-4.
Dưới đây là một ví dụ mẫu về Laravel documentation hợp lệ. Lưu ý rằng đằng sau thuộc tính @param
là hai khoảng trắng, tiếp theo là kiểu của tham số, và hai khoảng trắng và cuối cùng là tên biến:
/**
* 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)
{
//
}
Đừng lo lắng nếu code style của bạn không hoàn hảo! StyleCI sẽ tự động merge các bản sửa style cho bạn vào repository của Laravel sau khi các pull request được merge. Điều này cho phép chúng ta tập trung vào nội dung đóng góp thay vì phải tập trung vào code style.
Quy tắc ứng xử của Laravel có nguồn gốc từ quy tắc ứng xử của Ruby. Mọi vi phạm quy tắc ứng xử có thể được báo cáo cho Taylor Otwell ([email protected]):
entry