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
strategy
a. Create wheniii. ChangeA. To work on
a new feature
REC
iv. ReleaseC. To prepare
a release
REC
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
integration
strategy
a. Integrate wheniii. ChangeE. After
code review
completed,
F. After
passing tests
in Dev.
Environment
REQ
J. As
frequently as
possible
REC
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
integration
mechanism
iii. ChangeA. fast forward
merge <Git command options>,
B. non-fast
forward
merge <Git command options>
REC
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: