Skip to content

Latest commit

 

History

History
50 lines (33 loc) · 3.47 KB

CONTRIBUTING.md

File metadata and controls

50 lines (33 loc) · 3.47 KB

How to contribute

First of all, thank you for wanting to contribute to ConfigR! We really appreciate all the awesome support we get from our community. We want to keep it as easy as possible to contribute changes that get things working in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.

Spaces not Tabs

Pull requests containing tabs will not be accepted. Make sure you set your editor to replace tabs with spaces.

Line Endings

The repository is configured to preserve line endings both on checkout and commit (the equivalent of autocrlf set to false). This means you are responsible for line endings. We recommend that you configure your diff viewer so that it does not ignore line endings. Any wall of pink pull requests will not be accepted.

Making Changes

  1. Fork on GitHub
  2. Clone your fork locally
  3. Configure the upstream repo (git remote add upstream [email protected]:config-r/config-r.git)
  4. Create a local branch (git checkout -b myBranch)
  5. Work on your feature
  6. Rebase if required (see below)
  7. Test the build locally by running rake (see 'How to build')
  8. Push the branch up to GitHub (git push origin myBranch)
  9. Send a Pull Request on GitHub

You should never work on a clone of master, and you should never send a pull request from master - always from a branch. The reasons for this are detailed below.

Handling Updates from Upstream/Master

While you're working away in your branch it's quite possible that your upstream master may be updated. If this happens you should:

  1. Stash any un-committed changes you need to
  2. git checkout master
  3. git pull upstream master
  4. git checkout myBranch
  5. git rebase master myBranch
  6. git push origin master - (optional) this this makes sure your remote master is up to date

This ensures that your history is "clean" i.e. you have one branch off from master followed by your changes in a straight line. Failing to do this ends up with several "messy" merges in your history, which we don't want. This is the reason why you should always work in a branch and you should never be working in, or sending pull requests from, master.

If you're working on a long running feature then you may want to do this quite often, rather than run the risk of potential merge issues further down the line.

Sending a Pull Request

While working on your feature you may well create several branches, which is fine, but before you send a pull request you should ensure that you have rebased back to a single "Feature branch" - we care about your commits, and we care about your feature branch; but we don't care about how many or which branches you created while you were working on it :-)

When you're ready to go you should confirm that you are up to date and rebased with upstream/master (see "Handling Updates from Upstream/Master" above), and then:

  1. git push origin myBranch
  2. Send a descriptive Pull Request on GitHub - making sure you have selected the correct branch in the GitHub UI!
  3. Wait for adamralph to merge your changes in and reformat all of your code because he has StyleCop OCD ;-)