...
| Branch | Description | Branches From | Merges To |
|---|---|---|---|
| master | Current release or release candidate | - | - |
| develop | New features scheduled for next minor release | - | master, hotfix-* (if appropriate) |
| hotfix-* | Bug fixes and minor changes scheduled for next bugfix release | master | master, develop |
| feature-* | Experimental or prioritized features | master for prioritized development, otherwise any suitable branch | develop, hotfix-* (if appropriate) |
...
Managing develop and Pull Requests
- Pull Requests should be assigned a Reviewer, contextually determined. Absent any other decision, the Reviewer is the Component Lead.
- The Reviewer should perform "appropriate" testing, such as pulling the commit to a local branch for testing, or applying a patch locally. The Reviewer may hand off for additional testing as needed.
- The Reviewer can perform the merge, or hand the PR to the Component Lead to merge.
- While develop is not guaranteed to be stable, it also shouldn't be left broken for extended periods of time. (Of course, in most cases "broken" is subjective, since only a small class of bugs will prevent the application from running at all.) Whoever discovers an issue owns it until handed off to someone else (eg: to fix, or to test the fix, or to merge the fix).
- In general, these guidelines are intentionally somewhat vague to allow for professional discretion.