The Master Branch always reflects a production ready state, and it is the branch that will be deployed to the production server. Only fully tested and approved releases are pushed to this branch. Only Project Match admins will be pushing to this branch.
The Development Branch is used for development of new features and integration of changes. Pull Requests are made from your local branches into the development branch, and it is only merged after it's checked by other members of the team.
Feature branches are branched off from Development, and then merged back in once the feature is completed. All branches should following the naming convention, per the examples below:
- Before you create a new branch or merge a branch, ensure that you pull changes from origin/development (central repository) to ensure that your local repository is up to date.
- Once you have merged your changes, ensure you push those to origin/development to make them available to the rest of the team.
- As you continue working on a branch, make sure you rungit pull origin development frequently (at least once a day) so that your branch doesn’t get left behind, and to decrease the likelihood of merge conflicts.
- Branch names should start with either bug, feature, refactor, or style.
- Descriptors should be hyphenated:
- When several people are working on the same feature, it might be convenient to have personal feature branches and a team-wide feature branch. Merge, at will, the personal branches to the team-wide branch. Eventually, the team-wide branch will be merged to "master". Use the following naming convention:
$ git checkout -b feature-a/master # team-wide branch$ git checkout -b feature-a/maria # Maria's personal branch$ git checkout -b feature-a/nick # Nick's personal branch
- Delete your branch from the upstream repository after it's merged, unless there is a specific reason not to.