Commit 385b776b authored by Franz Liedke's avatar Franz Liedke

Docs: Finish section on pull request guidelines.

parent f80d694a
...@@ -32,7 +32,13 @@ Once certain milestones have been reached and/or Taylor Otwell and the Laravel t ...@@ -32,7 +32,13 @@ Once certain milestones have been reached and/or Taylor Otwell and the Laravel t
<a name="pull-requests"></a> <a name="pull-requests"></a>
## Pull Requests ## 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* *Further Reading*
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment