- Fork the repo.
- Checkout the branch you want to make changes on:
- Master if you make changes to the code that are not backward compatible.
- Default branch when adding new features.
- Branch before the default if you are fixing a bug for an existing feature (or the default/master branch if the feature was introduced in that version).
- Install dependencies:
composer install. - Create branch, e.g.
feature-fooorbugfix-bar. - Make changes.
- If you are adding functionality or fixing a bug - add a test!
- Fix project itself:
php php-cs-fixer fix. - Regenerate readme:
php php-cs-fixer readme > README.rst. Do not modifyREADME.rstmanually! - Check if tests pass:
phpunit(4.x or 5.x)
You can do some things to increase the chance that your pull request is accepted the first time:
- Submit one pull request per fix or feature.
- If your changes are not up to date - rebase your branch on the parent branch.
- Follow the conventions used in the project.
- Remember about tests and documentation.
- Don't bump version.
There is a cookbook with basic instructions on how to build a new fixer. Consider reading it before opening a PR.
- PSR-1: Basic Coding Standard
- PSR-2: Coding Style Guide
- PSR-4: Autoloading Standard
- PSR-5: PHPDoc (draft)
- Symfony Coding Standards
- Symfony Documentation Standards
- Keep the order of class elements: static properties, instance properties, constructor (or setUp for PHPUnit), destructor (or tearDown for PHPUnit), static methods, instance methods, magic static methods, magic instance methods.