[skip ci] Improve the Contributing Guide
with more detailed steps and command line examples.
This commit is contained in:
parent
549e1a6b54
commit
5a384a3865
|
@ -48,42 +48,47 @@ backward compatibility has a very good reason for doing so.
|
||||||
|
|
||||||
Here's a quick guide:
|
Here's a quick guide:
|
||||||
|
|
||||||
1. Fork the repo, clone it, create a thoughtfully-named branch for your changes,
|
1. Fork the repo.
|
||||||
and install the development dependencies by running `bundle install`.
|
|
||||||
|
|
||||||
2. Begin by running the tests. We only take pull requests with passing tests,
|
2. Create a thoughtfully-named branch for your changes (`git checkout -b my-new-feature`).
|
||||||
|
|
||||||
|
3. Install the development dependencies by running `bundle install`.
|
||||||
|
|
||||||
|
4. Begin by running the tests. We only take pull requests with passing tests,
|
||||||
and it's great to know that you have a clean slate:
|
and it's great to know that you have a clean slate:
|
||||||
|
|
||||||
$ bundle exec rake spec
|
$ bundle exec rake spec
|
||||||
|
|
||||||
The test suite runs by default with SQLite3. To run the test suite with PostgreSQL or MySQL, use:
|
The test suite runs by default with SQLite3. To run the test suite with PostgreSQL or MySQL, use:
|
||||||
|
|
||||||
$ DB=postgresql bundle exec rake spec
|
$ DB=postgresql bundle exec rake spec (`DB=pg` & `DB=postgres` work too)
|
||||||
$ DB=mysql bundle exec rake spec
|
$ DB=mysql bundle exec rake spec
|
||||||
|
|
||||||
3. Hack away! Please use Ruby features that are compatible down to Ruby 1.9.
|
5. Hack away! Please use Ruby features that are compatible down to Ruby 1.9.
|
||||||
Since version 1.5, Ransack no longer maintains Ruby 1.8 compatibility.
|
Since version 1.5, Ransack no longer maintains Ruby 1.8 compatibility.
|
||||||
|
|
||||||
4. Add tests for your changes. Only refactoring and documentation changes
|
6. Add tests for your changes. Only refactoring and documentation changes
|
||||||
require no new tests. If you are adding functionality or fixing a bug, we
|
require no new tests. If you are adding functionality or fixing a bug, we
|
||||||
need a test!
|
need a test!
|
||||||
|
|
||||||
5. Make the tests pass.
|
7. Make the tests pass.
|
||||||
|
|
||||||
6. Update the Change Log. If you are adding new functionality, document it in
|
8. Update the Change Log. If you are adding new functionality, document it in
|
||||||
the README.
|
the README.
|
||||||
|
|
||||||
7. Do not change the version number; we will do that on our end.
|
9. Commit your changes (`git commit -am 'Add feature/fix bug/improve docs'`).
|
||||||
|
|
||||||
8. If necessary, rebase your commits into logical chunks, without errors.
|
10. If necessary, rebase your commits into logical chunks, without errors. To
|
||||||
|
interactively rebase and cherry-pick from, say, the last 10 commits:
|
||||||
|
`git rebase -i HEAD~10`, then `git push -f`.
|
||||||
|
|
||||||
9. Push the branch up to your fork on Github and submit a pull request. If the
|
11. Push the branch up to your fork on Github
|
||||||
changes will apply cleanly to the latest stable branches and master branch,
|
(`git push origin my-new-feature`) and from Github submit a pull request to
|
||||||
you will only need to submit one pull request.
|
Ransack's `master` branch.
|
||||||
|
|
||||||
10. If your pull request only contains documentation changes, please remember to
|
12. If your pull request only contains documentation changes, please remember
|
||||||
add `[skip ci]` to your commit message so the Travis test suite doesn't run
|
to add `[skip ci]` to the beginning of your commit message so the Travis
|
||||||
needlessly.
|
test suite doesn't :runner: needlessly.
|
||||||
|
|
||||||
At this point you're waiting on us. We like to at least comment on, if not
|
At this point you're waiting on us. We like to at least comment on, if not
|
||||||
accept, pull requests within three business days (and, typically, one business
|
accept, pull requests within three business days (and, typically, one business
|
||||||
|
@ -91,14 +96,14 @@ day). We may suggest some changes or improvements or alternatives.
|
||||||
|
|
||||||
Some things that will increase the chance that your pull request is accepted:
|
Some things that will increase the chance that your pull request is accepted:
|
||||||
|
|
||||||
* Use idiomatic Ruby and follow the syntax conventions below.
|
|
||||||
* Include tests that fail without your code, and pass with it.
|
* Include tests that fail without your code, and pass with it.
|
||||||
* Update the README, the change log, the wiki documentation... anything that is
|
* Update the README, the change log, the wiki documentation... anything that is
|
||||||
affected by your contribution.
|
affected by your contribution.
|
||||||
|
* Use idiomatic Ruby and follow the syntax conventions below.
|
||||||
|
|
||||||
Syntax:
|
Syntax:
|
||||||
|
|
||||||
* Two spaces, no tabs.
|
* Indent with two spaces, no tabs.
|
||||||
* 80 characters per line.
|
* 80 characters per line.
|
||||||
* No trailing whitespace. Blank lines should not have any space.
|
* No trailing whitespace. Blank lines should not have any space.
|
||||||
* Prefer `&&`/`||` over `and`/`or`.
|
* Prefer `&&`/`||` over `and`/`or`.
|
||||||
|
|
Loading…
Reference in New Issue