Git Workflow
Adapted from the Chingu Voyage wiki
We are using the workflow model described in the Voyage wiki. This model is based on the assumption that your team will set up a skeleton repo in GitHub from which all team members will then clone to their computers.
A three level hierarchy of branches is created through which changes are promoted.
They are individual branches created by each developer when they are working on changes and bug fixes.
The convention we will use to name branches is the following:
type/#number-description
for example feature/#12-login
type represents the type of branch and should be one of the four following options: bug, feature, refactor and style.
number is the number identifying the issue. The issue numbers are displayed with a # in GitHub (e.g. #12) but not in Waffle. Update: Include the # in the branch name, Waffle doesn't seem to like it when it's not there.
description should be a short description as a reminder of the purpose of the branch.
See Working with Waffle for more information on naming branches.
Reflects the candidate code for the next release. Developers work in working branches, which are then pulled into this branch. All code pulled into this branch must be tested and undergo peer review as part of the PR process.
Only updated from PR's from the development branch for release. This branch always reflects the current production release.
- Once the skeletal repo is built in GitHub team members will clone it to their individual computers. Working branches are created for specific features and tasks (like bug fixes) you will be called upon to perform.
- All normal development activities occur on team members individual computers. Commits should be frequent and each commit should have a discrete, atomic purpose.
- Changes should be frequently push to the working branch on GitHub that matches the one on individual computers. This ensures that if a computer is lost, stolen, or malfunctions your work will still be available to the rest of your team.
- From time-to-time you may need to pull working branches to your individual computer. For example, when you are helping another team member with one of their tasks.
- Once a feature has been unit tested a Pull Request (PR) should be created to fold it into the development branch. It's always a good idea to require that PR's be reviewed by another member of the team. This helps to ensure that the quality of the app is maintained.
- When a group of features are ready to be promoted to Production they should be thoroughly tested together an then a Pull Request created to move them into the master branch which reflects the code base that's in Production or soon to be promoted to Production.
- Once the PR to the master branch has been completed you are then ready to release its contents into your Production runtime environment.