Home

Workflow guidelines for project

Create descriptive branches for working on features or fixes.
- e.g. refactor-authentication, user-content-cache-key, make-retina-avatars,

Whenever you add, edit, or delete a file, you should be making a commit, and adding them to your branch.
Commits should create a transparent history of your work that others can follow to understand WHAT you've done and WHY.

Pull Requests initiate discussion about your commits.
You can open a Pull Request at any point during the development process:
- When you have little or no code but want to share some screenshots or general ideas.
- When you're stuck and need help or advice.
- When you're ready for someone to review your work. Use GitHub's @mention system in your Pull Request message to ask for feedback from specific people or teams.

Once a Pull Request has been opened, the person or team reviewing your changes may have questions or comments.
- Does the coding style match project guidelines?
- Does the change have unit tests?
- Maybe everything looks great and props are in order!
Pull Requests should encourage and capture this type of conversation.
You can also continue to push to your branch in light of discussion and feedback about your commits.
If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change.

With GitHub, you can deploy from a branch for final testing in production before merging to master.
Once your Pull Request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production.
If your branch causes issues, you can roll it back by deploying the existing master into production.

Once verified in production, we can merge the code into master.
Incorporating keywords into the text of your Pull Request helps associate issues with code.
When the Pull Request is merged the related issues are also closed.
e.g. Closes #32 would close issue number 32 in the repository.