Git Flow and Review Process
Teagan Glenn
Teagan42
Senior Automation Consultant
Turnberry Solutions
Comcast
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
Benefits
- 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
Approved
Only approve a Pull Request when any and all of your blocking comments have been addressed and you have tested locally.
Blocked
If local testing produced errors or unexpected behavior, or if you have any blocking comments that have not been addressed by the developer
Releases
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
Git Flow and Review Process
By Teagan Glenn
