Git Flow

Keeping the codebase in a good state is difficult. It is all too easy to just make a fix on master and hope things work out. Such development can be troublesome when it comes to merges and fixes. This is why we've introduced git-flow to the repository.

NOTE: If you are concerned about remembering commands, there is a git-flow completion plugin for BASH and zsh.

Branching model

There is a really good article on the git-flow branching model, but for our purposes, I've summarized below:

General Workflow

1. Create a feature (git flow feature start MYFEATURE)
2. Work on the feature normally, committing to that branch, and occasionally pulling from dev (git pull origin dev, git add ., git commit, etc)
3. When work on a feature is complete, submit a pull request to have the code integrated into dev
4. When the code review is completed satisfactorily, it will be merged into dev (git flow feature finish MYFEATURE)

See the article for more details.

Branch Details

• Master
  • Bulletproof; this is what is deployed on social-referral
• Hotfix
  • If serious issues are found, we create hotfix branches to get things fixed ASAP (git flow hotfix start HOTFIXNAME)
  • Note that hotfixes are not merged into existing release branches
• Release
  • The features for release X are pretty much ready to go. Dot the i's and cross the t's and we're ready for a new version! (git flow release start 0.X)
• Dev
  • This is where code intermingles. Feature branches are merged into here after code review, as are hotfixes and release branches
• Feature Branches
  • This is where the majority of the work occurs