1 Drush is built by people like you! Please [join us](https://github.com/drush-ops/drush).
3 ## Git and Pull requests
4 * Contributions are submitted, reviewed, and accepted using GitHub pull requests.
5 * The latest changes are in the `master` branch. PR's should initially target this branch.
6 * Try to make clean commits that are easily readable (including descriptive commit messages!)
7 * Test before you push. Get familiar with Unish, our test suite. See the test-specific [README.md](tests/README.md). Optionally run tests in the provided Docker containers.
8 * We maintain branches named 9.x, 8.x, etc. These are release branches. From these branches, we make new tags for patch and minor versions.
10 ## Development Environment
11 * You may choose to use the docker-compose file in root directory for an optimized environment.
12 * See `composer run-script -l` for a list of helper scripts.
15 * Do write comments. You don't have to comment every line, but if you come up with something thats a bit complex/weird, just leave a comment. Bear in mind that you will probably leave the project at some point and that other people will read your code. Undocumented huge amounts of code are nearly worthless!
16 * We use [PSR-2](http://www.php-fig.org/psr/psr-2/) in the /src directory. [Drupal's coding standards](https://drupal.org/coding-standards) are still used in the includes directory (deprecated code).
17 * Keep it compatible. Do not introduce changes to the public API, or configurations too casually. Don't make incompatible changes without good reasons!
20 * The docs are in the [docs](docs) and [examples](examples) folders in the git repository, so people can easily find the suitable docs for the current git revision. You can read these from within Drush, with the `drush topic` command.
21 * Documentation should be kept up-to-date. This means, whenever you add a new API method, add a new hook or change the database model, pack the relevant changes to the docs in the same pull request.
projects / yaffs-website / blob