GitHub Flow

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:

Characterisation of GitHub Flow workflow in our framework ( ✓ – Relation Role-Branch, REQ – Requirement, REC – Recommendation, PRO – Prohibition, ALL – Allowed) :

CategoryFeature – Sub-featurePrimary roleValues / Options / 2ry roleEnforcement / SelectionAttributes
0. Framework setupb. Assign rolei. MainA. Master
iii. ChangeB. Develop,
D. Feature,
E. Topic,
F. Production,
G. Release,
R. Fix,
S. HotFix,
T. BugFix
iv. ReleaseA. Master
vi. FixB. Develop,
D. Feature,
E. Topic,
F. Production,
G. Release,
R. Fix,
S. HotFix,
T. BugFix
3. Syncingc. Pull requestiii. ChangeA. <Git command options> R<rr>RECR<rr> = R0
vi. FixA. <Git command options> R<rr>RECR<rr> = R0
d. Direction – I. Upstreamiii. Changei. Main R<rr>REQR<rr> = R0
iv. Release R<rr>REQR<rr> = R0
vi. Fixi. Main R<rr>REQR<rr> = R0
iii. Change R<rr>REQR<rr> = R0
4. Branching
strategy
a. Create wheniii. ChangeA. To work on
a new feature
REQ
vi. FixB. To generate a fixREQ
b. Create fromiii. Changei. MainREQ
vi. Fixiv. ReleaseREQ
5. Code
integration
strategy
a. Integrate wheniii. ChangeE. 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. FixE. After code
review
completed,
F. After tests
passing in Dev.
Environment,
H. After tests
passing in
Production
REC
b. Integrate intoiii. Changei. Main R<rr>REQR<rr> = R0
iv. Release R<rr>REQR<rr> = R0
vi. Fixi. Main R<rr>REQR<rr> = R0
iii. Change R<rr>REQR<rr> = R0
c. Code review mechanismiii. ChangeC. Through
pull/merge
request
REC
vi. FixC. Through
pull/merge
request
REC
6. Additional featuresa. Development conventions – II. State of the development linei. MainA. Production-ready and broken code not allowedREQ
iv. ReleaseA. Production-ready and broken code not allowedREQ

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: