Skip to content

Commit

Permalink
Merge pull request #121 from dougborg/contribution_documentation_update
Browse files Browse the repository at this point in the history
Contribution Guidelines Update Re: Branching, Take 2
  • Loading branch information
andsens committed Oct 14, 2014
2 parents ecfaa2a + 172b62f commit 6b0c697
Showing 1 changed file with 11 additions and 5 deletions.
16 changes: 11 additions & 5 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,15 +18,21 @@ and which shell you used (type `echo $SHELL` in your terminal if you are unsure)


### Reproducing ###
Unless you ran in to a [heisenbug](http://en.wikipedia.org/wiki/Heisenbug),
it should be possible to reproduce the bug in a testing environment.
To that end run `$HOME/.homesick/repos/homeshick/test/interactive` and reproduce the bug.
Unless you ran in to a [heisenbug](http://en.wikipedia.org/wiki/Heisenbug),
it should be possible to reproduce the bug in a testing environment.
To that end run `$HOME/.homesick/repos/homeshick/test/interactive` and reproduce the bug.
This script drops you into a new shell where `$HOME` is set to an (almost) empty temporary folder.
If you cannot reproduce the bug there, the error is likely with your setup and not homeshick.
Otherwise attach the commands you executed in that environment to the issue.

## Pull requests ##

### Branching
**Work from and create pull requests on the `development` branch, not `master`.**

`master` always represents the latest release since that is the way homeshick updates itself. The
`development` branch is where work is done for the next release version of homeshick.

### Code style ###
* Indent with tabs and align with spaces.
* Always use double brackets for `if` blocks
Expand All @@ -42,8 +48,8 @@ The PR should clearly describe what problem the change fixes.
A feature addition with no justification and use-case will be rejected.

### Testing ###
Unless the code-change is a refactor, you should always add unit tests.
When fixing a bug there should be a new test case that fails with the old code and succeeds with the new code.
Unless the code-change is a refactor, you should always add unit tests.
When fixing a bug there should be a new test case that fails with the old code and succeeds with the new code.
When introducing a new feature, it should be tested extensively, a single test case will not suffice.

Note that bats does not fail a test case when using double brackets.
Expand Down

0 comments on commit 6b0c697

Please sign in to comment.