Git rules

Commit often, with a detailed comment about the commit, and read this article about the committing right way.
We've also agreed on using semantic commit messages, you can read more about them here and here. Basically, The commit message should be structured as follows:

<type of commit>[optional scope]: <short description>

[optional body]

[optional footer]

Limit the subject line to 50 characters, commits should be as focused as possible, few other things to take attention to:
- Capitalize on the subject line.
- Do not end the subject line with a period.
- Use imperative mood in the commit msg

This should be discussed further

Branch out from master
Never push directly to the master branch. Make Pull Request.
PR should be reviewed by another team member before changes are merged to master
PR should pass Travis CI build before merging to master
PR should be squashed before merging
branch naming should be related to ticket you're working on, so if you are working on user story/feature with number #8 your branch should be named feature/8, if you are working on bugfix with the same number your branch should be named fix/8 and so on.
delete your branches after they are merged to the master so that they don't go stale
As you work on that branch, periodically rebase or merge from master to get your branch up to date.

git rebase origin/master
git merge origin/master

Commit and push to your branch as many times as you need. These commits will eventually be squashed.
We have commit hooks for linting and unit tests. It will not let you commit if there are linting issues or when there's a broken unit test.
When your branch is ready, submit a pull request:
- Connect your pull request to an issue with ZenHub:
- Use the Connect with an Issue button below the conflicts confirmation section to connect your pull request to any issue that lives in your ZenHub Board.

More info about using git in a professional environment:

Provide feedback