In this workflow, all branches branch out from a wide trunk (master branch) and never get merged back. This model should reflect much better the way that comes up naturally when working with Git and making sure that continuous integration principles are used.
Main characteristics:
- All development happens in Master
- Developers should rebase their changes frequently to follow the latest origin/master
- Short-lived local branches are ok but should be integrated with origin/master when need to share something
- Shared remote branches should be avoided
- Releases get their own tags
- Hot fixes get added to the release branch and cherry-picked to master
- No normal merges, only fast-forward merges so instead use either rebase or cherry-pick
Authors: – Jussi Judin, 2016.
Links to original descriptions of Cactus Model workflow:
Characterisation of Cactus Model 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, B. Develop, G. Release | ✓ | |
| ii. Integration | A. Master, B. Develop, D. Feature, E. Topic, F. Production, G. Release | ✓ | |||
| iii. Change | A. Master, B. Develop, D. Feature, E. Topic, F. Production, G. Release, R. Fix, S. HotFix, T. BugFix | ✓ | |||
| iv. Release | G. Release, R. Fix | ✓ | |||
| 2. File management | d. Tags | iv. Release | A. <Git command options> | REC | |
| 3. Syncing | d. Direction – I. Upstream | iii. Change | i. Main R<rr> | REQ | R<rr> = R0 |
| iv. Release | i. Main R<rr> | REC | R<rr> = R0 | ||
| d. Direction – II. Downstream | i. Main | iii. Change R<rr> | REQ | R<rr> = R3 | |
| 4. Branching strategy | a. Create when | iii. Change | A. To work on a new feature | REQ | |
| iv. Release | C. To prepare a release | REQ | |||
| b. Create from | iii. Change | i. Main | REQ | ||
| iv. Release | i. Main | REQ | |||
| c. Remove when | iii. Change | A. Integration completed | REQ | ||
| e. Branch lifetime – I. Short-lived | iii. Change | A. <max. days for short-lived branch> | REQ | max-days = 7 | |
| e. Branch lifetime – II. Long-lived | i. Main | A. <min. days for long-lived branch> | REC | min-days = 7 | |
| 5. Code integration strategy | a. Integrate when | i. Main | J. As frequently as possible | REC | |
| iii. Change | E. After code review completed | REC | |||
| b. Integrate into | i. Main | iii. Change R<rr> | REQ | R<rr> = R3 | |
| iii. Change | i. Main R<rr> | REQ | R<rr> = R0 | ||
| iv. Release | i. Main R<rr> | REC | R<rr> = R0 | ||
| c. Code review mechanism | iii. Change | A. Staged | REC | ||
| d. Code integration mechanism | i. Main | A. fast forward merge <Git command options>, B. non-fast forward merge <Git command options> , E. fetch with rebase and merge <Git command options> F. through bot or webhook | PRO | ||
| C. rebase <Git command options> , D. cherry-pick <Git command options> | REQ | ||||
| iii. Change | A. fast forward merge <Git command options>, B. non-fast forward merge <Git command options> , E. fetch with rebase and merge <Git command options> F. through bot or webhook | PRO | |||
| C. rebase <Git command options> , D. cherry-pick <Git command options> | REQ | ||||
| iv. Release | A. fast forward merge <Git command options>, B. non-fast forward merge <Git command options> , E. fetch with rebase and merge <Git command options> F. through bot or webhook | PRO | |||
| C. rebase <Git command options> , D. cherry-pick <Git command options> | 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 and R3 is the working/contributor repository.
Comparison against other workflows:
