Feature Branch

This workflow is characterised by considering that all development of new features happens over a dedicated feature branch

Main characteristics:

  • Multiple developers working on a feature without affecting master
  • Teams using pull requests to discuss and review code before merging it into master
  • Flow: checkout master, create new branch off of master, make and commit changes, push branch to remote, create pull request (if conflicts pull -rebase and push again), further contributions pull locally before pull request
  • Recommended for continuous integration/deployed environments, code review and collaboration, large teams/projects, keeping master stable
  • Long-lived branches can have merge conflicts, best to keep features small

Authors: N/A

Links to original descriptions of Feature Branch workflow:

Characterisation of Feature Branch workflow in our framework ( ✓ – Relation Role-Branch, REQ – Requirement, REC – Recommendation, PRO – Prohibition, ALL – Allowed):

CategoryFeature – Sub-featurePrimary roleValues / Options / 2ry role Enforcement / Selection Attributes
0. Framework Setupb. Assign rolei. MainA. Master
iii. ChangeA. Master,
B. Develop,
D. Feature,
E. Topic,
F. Production,
G. Release,
R. Fix,
S. HotFix,
T. BugFix
v. FixR. Fix
3. Syncingc. Pull requestiii. ChangeA. <Git command options> R<rr>RECR<rr> = R0
d. Direction – I. Upstreamiii. Changei. Main R<rr>REQR<rr> = R0
iii. Change R<rr>RECR<rr> = R0
4. Branching
a. Create wheniii. ChangeA. To work on
a new feature
b. Create fromiii. Changei. MainREQ
e. Branch lifetime – I. Short-livediii. Change A. <max. days for short-lived branch>RECmax-days = 7
5. Code
a. Integrate wheniii. ChangeE. After code
b. Integrate intoiii. Changei. Main R<rr>REQR<rr> = R0
iii. Change R<rr>RECR<rr> = R0
c. Code review mechanismiii. ChangeA. StagedREC
C. Through pull/merge requestREC
d. Code
iv. ReleaseC. rebase <Git command options>REC
6. Additional featuresa. Development conventions – II. State of the development linei. MainB. Not 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: