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:
- https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
- https://www.codingblocks.net/podcast/comparing-git-workflows/
- https://buddy.works/blog/5-types-of-git-workflows
Characterisation of Feature Branch 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 | ✓ | |||
| v. Fix | R. Fix | ✓ | |||
| 3. Syncing | c. Pull request | iii. Change | A. <Git command options> R<rr> | REC | R<rr> = R0 |
| d. Direction – I. Upstream | iii. Change | i. Main R<rr> | REQ | R<rr> = R0 | |
| iii. Change R<rr> | REC | R<rr> = R0 | |||
| 4. Branching strategy | a. Create when | iii. Change | A. To work on a new feature | REQ | |
| b. Create from | iii. Change | i. Main | REQ | ||
| e. Branch lifetime – I. Short-lived | iii. Change | A. <max. days for short-lived branch> | REC | max-days = 7 | |
| 5. Code integration strategy | a. Integrate when | iii. Change | E. After code review completed | REC | |
| b. Integrate into | iii. Change | i. Main R<rr> | REQ | R<rr> = R0 | |
| iii. Change R<rr> | REC | R<rr> = R0 | |||
| c. Code review mechanism | iii. Change | A. Staged | REC | ||
| C. Through pull/merge request | REC | ||||
| d. Code integration mechanism | iv. Release | C. rebase <Git command options> | REC | ||
| 6. Additional features | a. Development conventions – II. State of the development line | i. Main | B. Not 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:
