Basic guidelines for development, deployment, and source control
When writing code it is generally a good idea to try and match your formatting to that of any existing code in the same file, or to other similar files if you are writing new code. Consistency of layout is far more important that the layout itself as it makes reading code much easier. That being said there are some guidelines.
- Use single quotes for strings whenever possible
- User helpers for html whenever possible (ie.
image_tag
,link_to
,icon
, etc) - Use tabs for indentation, its easier to write, more space to read
- Annotate new or updated models with the
annotate
gem - Comment any code that is a 'hack' or is not immediately obvious what its purpose is
Issues should drive most of the development on this project. Do your best to keep your assigned issues updated and referenced in commits and pull requests. Any known bugs in the master codebase should have an issue created for them. If there are no issues to work on, you may contact arempe93 or doctorup
-
Committing
- Should strive to have as few changes per commit as possible. When it's not: add a
;
between changes in the message (ie.Adds new static page; Fixes default layout for static pages
) - Remember that a patch is an action, so messages should begin with a verb. (ie.
Updates...
,Adds...
,Fixes...
- If possible, use GitHub's issue linking in commit messages
- Should strive to have as few changes per commit as possible. When it's not: add a
-
Branches
- Most coding should be done on branches once a baseline for the project is established
- Use intelligent branch names
- Create pull requests to merge your changes into the main codebase
Only the master branch should be deployed to Heroku. (This may change)