In this workflow, all developers work on a single open branch (trunk). This branch could be Master.
Main characteristics:
- Some cases with short-lived feature branches
- Full source code review
- Aimed for experienced and trusted (seasoned) developers
- Enforceable code style needed
- Less micro-management
- Fast iterations
- No pull requests
Authors: N/A
Links to original descriptions of Trunk-based Development workflow:
Characterisation of Trunk-based Development 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 | A. Master, B. Develop, D. Feature, E. Topic, F. Production, G. Release, R. Fix, S. HotFix, T. BugFix | ✓ | |||
| iv. Release | A. Master, G. Release | ✓ | |||
| 1. Repository setup and initialisation | a. Copy | A. Clone R<rr> | REC | R<rr> = R0 | |
| 3. Syncing | d. Direction – I. Upstream | i. Main | iii. Change R<rr> | REC | R<rr> = R0 |
| iii. Change | i. Main R<rr> | REQ | R<rr> = R0 | ||
| 4. Branching strategy | a. Create when | iii. Change | A. To work on a new feature | REC | |
| iv. Release | C. To prepare a release | REC | |||
| b. Create from | iii. Change | i. Main | REQ | ||
| iv. Release | i. Main | REQ | |||
| c. Remove when | iii. Change | 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 | ||
| e. Branch lifetime – II. Long-lived | i. Main | A. <min. days for long-lived branch> | REQ | min-days > 1 | |
| 5. Code integration strategy | a. Integrate when | iii. Change | E. After code review completed, F. After passing tests in Dev. Environment | REQ | |
| J. As frequently as possible | REC | ||||
| b. Integrate into | i. Main | iii. Change R<rr> | REC | R<rr> = R0 | |
| iii. Change | i. Main R<rr> | REQ | R<rr> = R0 | ||
| c. Code review mechanism | iii. Change | A. Staged | REC | ||
| d. Code integration mechanism | iii. Change | A. fast forward merge <Git command options>, B. non-fast forward merge <Git command options> | REC | ||
| iv. Release | D. cherry-pick <Git command options> | REC | |||
| 6. Additional features | a. Development conventions – II. State of the development line | i. Main | A. Production-ready and broken code not allowed | REQ | |
| iii. Change | 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:
