Be sure your feature branch is correctly named to reference the corresponding issue in JIRA. (e.g. BUS-275_my_new_feature)
A few sentences describing the overall goals of the pull request's commits.
List general components of the application that this PR will affect:
Please delete options that are not relevant.
- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
- Breaking change (fix or feature that would cause existing functionality to not work as expected)
- This change requires a documentation update
- Tests
- Documentation
Outline the steps to test or reproduce the PR here.
git pull --prune
git checkout <feature_branch>
bundle; script/server
Local Docker Container: YES | NO
Sandbox: YES | NO
List related PRs against other branches and projects:
repo | branch | PR |
---|---|---|
other_pr_production | other_pr_production | link |
other_pr_master | other_pr_master | link |
A PR template would be an awesome addition to our git workflow! I think trying to find a balance between what should be in a PR and what should be in the corresponding JIRA ticket (because most every PR will have a PBI) is key. I have the following suggestions/simplifications:
[ ] This change requires a salt config update
I like the idea of a TODO list as a reminder of good things to check. Here is another I think is a good reminder.
[ ] Commented code, particularly in hard-to-understand areas
These are just my suggestions (as one user of our github) mainly in order to keep friction low in the PR process (we already have quite a bit for any given PR). And perhaps there is room to customize PR templates between our git repos in case some sections prove useful to other repo's.