This workflow is a simplified model from the GitFlow workflow that allows continuous testing and deployment.
Main characteristics:
- Anything in the Master branch is deployable
- To work on something new, create a descriptively named branch off of Master (i.e., new-oauth2-scopes)
- Commit to that branch locally and regularly push your work to the same named branch on the server
- When you need feedback or help, or you think the branch is ready for merging, open a pull request
- After someone else has reviewed and signed off on the feature, you can merge it into master
- Once it is merged and pushed to Master, you can and should deploy immediately
Authors: GitHub, Inc.
Links to original descriptions of GitHub Flow workflow:
- https://guides.github.com/introduction/flow/
- https://www.endpoint.com/blog/2014/05/02/git-workflows-that-work
- https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf
Characterisation of GitHub Flow workflow in our framework ( ✓ – Relation Role-Branch, REQ – Requirement, REC – Recommendation, PRO – Prohibition, ALL – Allowed) :
| Category | Feature – Sub-feature | Primary role | Values / Options / 2ry role | Enforcement / Selection | Attributes |
|---|---|---|---|---|---|
| 0. Framework setup | b. Assign role | i. Main | A. Master | ✓ | |
| iii. Change | B. Develop, D. Feature, E. Topic, F. Production, G. Release, R. Fix, S. HotFix, T. BugFix | ✓ | |||
| iv. Release | A. Master | ✓ | |||
| vi. Fix | B. Develop, D. Feature, E. Topic, F. Production, G. Release, R. Fix, S. HotFix, T. BugFix | ✓ | |||
| 3. Syncing | c. Pull request | iii. Change | A. <Git command options> R<rr> | REC | R<rr> = R0 |
| vi. Fix | A. <Git command options> R<rr> | REC | R<rr> = R0 | ||
| d. Direction – I. Upstream | iii. Change | i. Main R<rr> | REQ | R<rr> = R0 | |
| iv. Release R<rr> | REQ | R<rr> = R0 | |||
| vi. Fix | i. Main R<rr> | REQ | R<rr> = R0 | ||
| iii. Change R<rr> | REQ | R<rr> = R0 | |||
| 4. Branching strategy | a. Create when | iii. Change | A. To work on a new feature | REQ | |
| vi. Fix | B. To generate a fix | REQ | |||
| b. Create from | iii. Change | i. Main | REQ | ||
| vi. Fix | iv. Release | REQ | |||
| 5. Code integration strategy | a. Integrate when | iii. Change | E. After code review completed, F. After tests passing in Dev. Environment, H. After tests passing in Production | REC | |
| J. As frequently as possible | REQ | ||||
| vi. Fix | E. After code review completed, F. After tests passing in Dev. Environment, H. After tests passing in Production | REC | |||
| b. Integrate into | iii. Change | i. Main R<rr> | REQ | R<rr> = R0 | |
| iv. Release R<rr> | REQ | R<rr> = R0 | |||
| vi. Fix | i. Main R<rr> | REQ | R<rr> = R0 | ||
| iii. Change R<rr> | REQ | R<rr> = R0 | |||
| c. Code review mechanism | iii. Change | C. Through pull/merge request | REC | ||
| vi. Fix | C. Through pull/merge request | REC | |||
| 6. Additional features | a. Development conventions – II. State of the development line | i. Main | A. Production-ready and broken code not allowed | REQ | |
| iv. Release | A. Production-ready and broken code not allowed | REQ |
Notes. All the features that are not included in this characterisation, whilst they are not in conflict with any of the features stated here, are assumed to be allowed (ALL). R0 is the source/reference repository.
Comparison against other workflows:
