This workflow includes a branching model well suited for collaboration and scaling in the development team, by allowing parallel development, and offering a release staging area and support for emergency fixes
Main characteristics:
- Master branch ready to be released
- Versions tags off of master
- Main development branch: develop
- Features and Releases branches
- Feature branches merge back into develop after approval
- All work is done in a feature branch
- Develop merged into a release branch
- Hot fixes merged back into Master, Develop and Release branches
- Release merged into Master
- Master deployed to production (tag master with version number)
Authors: Vincent Driessen, 2010.
Links to original descriptions of GitFlow workflow:
- https://nvie.com/posts/a-successful-git-branching-model/
- https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
- https://www.endpoint.com/blog/2014/05/02/git-workflows-that-work
- http://drincruz.github.io/slides/git-workflow-comparison/#/types-of-workflows
- https://datasift.github.io/gitflow/IntroducingGitFlow.html
- https://www.codingblocks.net/podcast/comparing-git-workflows/
Characterisation of GitFlow 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, B. Develop | ✓ | |
| ii. Integration | A. Master, B. Develop | ✓ | |||
| iii. Change | D. Feature, E. Topic | ✓ | |||
| iv. Release | A. Master, G. Release | ✓ | |||
| vi. Fix | R. Fix, S. HotFix, T. BugFix | ✓ | |||
| 2. File management | d. Tags | i. Main | A. <Git command options> | REQ | |
| 3. Syncing | d. Direction – I. Upstream | iii. Change | ii. Integration R<rr> | REQ | R<rr> = R0 |
| iv. Release | i. Main R<rr> | REQ | R<rr> = R0 | ||
| ii. Integration R<rr> | REQ | R<rr> = R0 | |||
| vi. Fix | i. Main R<rr> | REQ | R<rr> = R0 | ||
| ii. Integration R<rr> | REQ | R<rr> = R0 | |||
| iv. Release R<rr> | REC | R<rr> = R0 | |||
| 4. Branching strategy | a. Create when | ii. Integration | D. To integrate work | REQ | |
| iii. Change | A. To work on a new feature | REQ | |||
| iv. Release | C. To prepare a release | REQ | |||
| vi. Fix | B. To generate a fix | REQ | |||
| b. Create from | ii. Integration | i. Main | REQ | ||
| iii. Change | i. Main | REQ | |||
| ii. Integration | REC | ||||
| iv. Release | PRO | ||||
| iv. Release | ii. Integration | REC | |||
| vi. Fix | i. Main | REC | |||
| c. Remove when | iii. Change | F. After integration was completed | REC | ||
| iv. Release | F. After integration was completed, G. After additional tests were completed, H. After code review/validation was completed | REC | |||
| vi. Fix | F. After integration was completed | REC | |||
| e. Branch lifetime – I. Short-lived | iii. Change | A. <max. days for short-lived branch> | REC | max-days <= 1 | |
| iv. Release | A. <max. days for short-lived branch> | REC | max-days <= 1 | ||
| vi. Fix | A. <max. days for short-lived branch> | REC | max-days <= 1 | ||
| e. Branch lifetime – II. Long-lived | i. Main | A. <min. days for long-lived branch> | REC | min-days > 1 | |
| ii. Integration | A. <min. days for long-lived branch> | REC | min-days > 1 | ||
| 5. Code integration strategy | a. Integrate when | iii. Change | C. When work completed | REQ | |
| iv. Release | E. After code review completed | REQ | |||
| vi. Fix | C. When work completed | REQ | |||
| b. Integrate into | iii. Change | ii. Integration R<rr> | REQ | R<rr> = R0 | |
| iv. Release | i. Main R<rr> | REQ | R<rr> = R0 | ||
| ii. Integration R<rr> | REQ | R<rr> = R0 | |||
| vi. Fix | i. Main R<rr> | REQ | R<rr> = R0 | ||
| ii. Integration R<rr> | REQ | R<rr> = R0 | |||
| iv. Release R<rr> | REC | R<rr> = R0 | |||
| d. Code integration mechanism | iii. Change | B. non fast-forward merge <Git command options> | REQ | ||
| iv. Release | B. non fast-forward merge <Git command options> | REQ | |||
| vi. Fix | B. non fast-forward merge <Git command options> | REQ | |||
| 6. Additional feature | a. Development conventions – II. State of the development line | i. Main | A. Production-ready and broken code not allowed | REQ | |
| a. Development convention – III. Release mechanism | A. New release based on previous | REQ | |||
| b. Branch naming conventions | ii. Integration | B. <development line> | REQ | devline = develop | |
| iv. Release | A. Semantic versioning (semver) | REC | |||
| D. <development line>-* | REQ | devline = release | |||
| vi. Fix | A. Semantic versioning (semver) | REC | |||
| D. <development line>-* | REQ | devline = hotfix, bugfix, fix | |||
| c. Supporting tools/mechanisms | A. Version bump | 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:
