|
|
@@ -32,7 +32,13 @@ Once certain milestones have been reached and/or Taylor Otwell and the Laravel t
|
|
|
<a name="pull-requests"></a>
|
|
|
## Pull Requests
|
|
|
|
|
|
-Contributing with pull requests.
|
|
|
+[GitHub pull requests](https://help.github.com/articles/using-pull-requests) are a great way for everyone in the community to contribute to the Laravel codebase. Found a bug? Just fix it in your fork and submit a pull request. This will then be reviewed, and, if found as good, merged into the main repository.
|
|
|
+
|
|
|
+In order to keep the codebase clean, stable and at high quality, even with so many people contributing, some guidelines are necessary for high-quality pull requests:
|
|
|
+
|
|
|
+- **Branch:** Unless they are immediate documentation fixes relevant for old versions, pull requests should be sent to the `develop` branch only. Make sure to select that branch as target when creating the pull request (GitHub will not automatically select it.)
|
|
|
+- **Documentation:** If you are adding a new feature or changing the API in any relevant way, this should be documented. The documentation files can be found directly in the core repository.
|
|
|
+- **Unit tests:** To keep old bugs from re-appearing and generally hold quality at a high level, the Laravel core is thoroughly unit-tested. Thus, when you create a pull request, it is expected that you unit test any new code you add. For any bug you fix, you should also add regression tests to make sure the bug will never appear again. If you are unsure about how to write tests, the core team or other contributors will gladly help.
|
|
|
|
|
|
*Further Reading*
|
|
|
|
Franz Liedke