Git Flow and Review Process

Teagan Glenn


Senior Automation Consultant

Turnberry Solutions


Branching Strategy

  • Master is current production code
  • Develop is for integrating features
  • Features are branched off Develop
    • Follow specific naming conventions
  • Hot-Fixes are branched of Master
    • Master is then back-merged to Develop
  • Releases are branched off develop
    • Tested in a staging/dev environment
    • Merged to Master

Example DiagramĀ 


  • Master is always stable and can be deployed any time
  • Develop allows flux, testing and CI
  • Integration with Jira
    • All work is visible in the ticket
  • Proper sem-ver tagging
  • Unified developer workflows

Pull Requests

  • Developer should have tested their own code
  • Documentation and unit tests should be written
  • Pull requests for features should be into Develop
  • Reviewers should:
    • Pull the branch locally
    • Test the feature
    • Test regular user workflow
  • Commenting
    • Inconsistent style
    • Ambiguous code
    • Missed edge cases
    • Error handling issues
    • Indicate: blocking, suggestion, question


Only approve a Pull Request when any and all of your blocking comments have been addressed and you have tested locally.


If local testing produced errors or unexpected behavior, or if you have any blocking comments that have not been addressed by the developer


This is up for debate, but usually releases are cut at the end of sprints to make consistent release schedule. This guideline does not apply to hot-fixes found in production needing to be addressed for the application to be used by our end-users