Single mainline Git workflow

workflow.md

Workflow

Single mainline Git workflow

The single mainline workflow constists of:

• a single mainline branch ("master")
• one short-lived feature branch per feature with a speaking branch name

Guidelines

• The master branch always has to be deployable
• Bugs are to be treated like a feature branche
• Merge through Pull Request

Development process

• To work on something new, create a descriptively named feature branch off of master (ie: new-oauth2-scopes)
• Commit to that branch locally and regularly push your work to the same named branch on remote
• When you need feedback or help, or you think the branch is ready for merging, open a Pull Request through remote
• Describe database changes in the Pull Request and attach Template or Fields export JSON files
• After someone else has reviewed and signed off on the feature, you can merge it into master (once the feature branch is merged onto master, both test and staging will be automatically deployed through a webhook)
• Apply database changes to test and staging
• Remove the local feature branch

Deployment proces to live application

• If possible apply database changes before manually deploying
• Do a manual deploy through deploybot onto master

Do's

• Always merge with --no-ff (Bitbucket does this by default)
• Always use a Pull Request to merge
• Always work in a feature branch

Don'ts

• Work directly on master

Todo

• Convert deploy process to the Otto open source project.
• Implement basic testing like coding style.
• Implement PhantomJS-based tool like DalekJS for automated user testing.

Source

• https://guides.github.com/introduction/flow/
• http://scottchacon.com/2011/08/31/github-flow.html
• http://fbrnc.net/blog/2014/12/keeping-it-simple-git-workflow