FM / env

/var/www/vhosts/ihelp.ro/httpdocs/vendor/m1/env/

/var/www/vhosts/ihelp.ro/httpdocs/vendor/m1/env

Name	Size	Mode	Actions
src/	-	0755	rm
.editorconfig	312	0644	edit dl rm
CHANGELOG.md	1052	0644	edit dl rm
composer.json	1454	0644	edit dl rm
CONDUCT.md	2150	0644	edit dl rm
CONTRIBUTING.md	1304	0644	edit dl rm
LICENSE.md	1141	0644	edit dl rm
README.md	15790	0644	edit dl rm

Edit: /var/www/vhosts/ihelp.ro/httpdocs/vendor/m1/env/CONTRIBUTING.md (1304B)

# Contributing

Contributions are **welcome** and will be fully **credited**.

We accept contributions via Pull Requests on [Github](https://github.com/m1/env).

## Pull Requests

- **[PSR-2 Coding Standard](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md)** - Check the code style with ``$ composer check-codestyle`` and fix it with ``$ composer fix-codestyle``.

- **Add tests!** - Your patch won't be accepted if it doesn't have tests.

- **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date.

- **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option.

- **Create feature branches** - Don't ask us to pull from your master branch.

- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests.

- **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting.

## Running Tests

``` bash
$ composer test
```

**Happy coding**!

# Contributing Contributions are **welcome** and will be fully **credited**. We accept contributions via Pull Requests on [Github](https://github.com/m1/env). ## Pull Requests - **[PSR-2 Coding Standard](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md)** - Check the code style with ``$ composer check-codestyle`` and fix it with ``$ composer fix-codestyle``. - **Add tests!** - Your patch won't be accepted if it doesn't have tests. - **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date. - **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option. - **Create feature branches** - Don't ask us to pull from your master branch. - **One pull request per feature** - If you want to do more than one thing, send multiple pull requests. - **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting. ## Running Tests ``` bash $ composer test ``` **Happy coding**!