Trunk-based Development

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):

CategoryFeature – Sub-featurePrimary roleValues / Options / 2ry roleEnforcement / SelectionAttributes
0. Framework setup b. Assign rolei. MainA. Master
iii. ChangeA. Master,
B. Develop,
D. Feature,
E. Topic,
F. Production,
G. Release,
R. Fix,
S. HotFix,
T. BugFix
iv. ReleaseA. Master,
G. Release
1. Repository setup and initialisationa. CopyA. Clone R<rr>RECR<rr> = R0
3. Syncingd. Direction – I. Upstreami. Mainiii. Change R<rr>RECR<rr> = R0
iii. Changei. Main R<rr>REQR<rr> = R0
4. Branching
a. Create wheniii. ChangeA. To work on
a new feature
iv. ReleaseC. To prepare
a release
b. Create fromiii. Changei. MainREQ
iv. Releasei. MainREQ
c. Remove wheniii. ChangeF. After integration was completedREC
e. Branch lifetime – I. Short-livediii. ChangeA. <max. days for short-lived branch>RECmax-days <= 1
iv. ReleaseA. <max. days for short-lived branch>RECmax-days <= 1
e. Branch lifetime – II. Long-livedi. MainA. <min. days for long-lived branch>REQmin-days > 1
5. Code
a. Integrate wheniii. ChangeE. After
code review
F. After
passing tests
in Dev.
J. As
frequently as
b. Integrate intoi. Mainiii. Change R<rr>RECR<rr> = R0
iii. Changei. Main R<rr>REQR<rr> = R0
c. Code review mechanismiii. ChangeA. StagedREC
d. Code
iii. ChangeA. fast forward
merge <Git command options>,
B. non-fast
merge <Git command options>
iv. ReleaseD. cherry-pick <Git command options>REC
6. Additional featuresa. Development conventions – II. State of the development linei. MainA. Production-ready and broken code not allowedREQ
iii. ChangeA. 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: