Workflow Catalogue

The table below lists the 50 workflows that we have discovered and included in our workflow catalogue. It also provides external sources for each workflow for further details. The workflows in italics were the first 26 upon which the current version of the framework was created.

Links on workflow names indicate that the workflow has been defined in our common framework, which allows detailed comparison with other workflows. These links will take you to the workflow definition based on our framework.

All development in main. Release and change branch off from main and must be merged back.*
BioGitFlowBased on GitFlow and using GitLab. Focused on the development of new features and hotfixes. *
BitBucketProduction and staging development lines. New versions from staging to production through pull requests except hotfixes. Other workflows allowed on the platform.*
BOINC FlowThe main branch is reliable and everyone should branch from it. Developers work on feature or bugfix branch and use pull requests to merge (peer-reviewed, unit, and automated testing). Delete feature and bugfix branches once merged.*
Cactus modelAll development in main branch. Change branches do not get merged back into master. Rebase commits instead. Cherry-pick from fix branches.*
CentralizedAll commits applied to the main branch.
* * * * *
CompartmentaliseBased on GitFlow. Aimed at multiple teams working on the same repository. Segregates features to limit the effect of deficient branching and code integration approaches *
COOP Cactus modelBased on Cactus model. Specifies how to and when to tag, create branches and prepare releases *
Dictator and Lieutenants (D&L)Developers use topic branches and rebase work on top of master (taken from reference repository). Lieutenants merge developers’ topic branches into their master branch. Dictator merges lieutenants’ master into its own master (pushed to reference repository).*
Feature branch (FB)All development of new features in change branches.* * *
FB with code reviewsVariation of FB workflow that uses pull requests to perform code reviews before merging*
ForkDevelopers with own forked repository, push changes first to local, maintainer integrates* * *
Fork & branchDesigned for collaborating in open source projects at GitHub. Focuses on setting up the local repository and using branching to organise work *
Fork & merge (GateKeeper)Variation of fork workflow with merge requests from developers when ready to integrate
and maintainer or gatekeeper reviews and accepts or rejects changes
* * *
Forks with feature branchesRecommends the creation of a local repository to work on dedicated feature branches to maintain a clean central repository *
GentooThe main branch used to integrate work and for deployment. Feature branches are recommended. Rebasing should be used first, then stage multiple commits and finally push them *
Git CommonAll commits on change branches, rebasing commits into main branch.*
Git MergeRelies on merging for code integration *
Git RebaseRelies on rebasing for code integration *
GitFlowParallel development using develop branch. Uses release and fix branches.* * * * * *
GitHubMain branch always deployable. Intensive use of pull requests.* * *
GitLabFeature-driven development with change branches and issue tracking. Upstream-first policy.* * *
GitWaterFlowInspired by semantic versioning. Uses tools to automate development. Promotes forward porting.*
Git workflow for development teams Repository write access restricted to release managers. Main branch stable. Dev branch for integration. Clear distinction between feature and fix branches. Uses pull requests for code integration *
IGSTK FlowDesigned for the development of health-related software. Uses change and release branches.*
MaintenanceFor hotfixes. Branches off from main and merges back into main and development branches*
MantidBased on GitHub Flow. Specifies naming conventions for branch creation. Enforces testing and the usage of pull requests for code integration *
MojoTechThe main branch is always in a ready-state. Rebasing and pull requests are encouraged. Naming convention for feature branches *
MuseScoreFork and clone to setup the working repository. Uses issue branches for work. Fetch from origin, rebase and push updated branch *
OneFlowSingle long-lived main with short-lived change, release and fix branches. Accumulative releases.* *
Open Source RepositoriesClone the main repository and add your fork as a remote. No commits on main branch. Use pull requests for changes but only one per branch *
PLEFlowUses two branching models to work at product and variant levels.*
PracticalCreate a backup repository. Gatekeeper or “czar” to check code integration. The main branch is for code integration. Squash merge feature branches. Use stashing to handle flow interruptions *
ProfessionalTrack main branch. Use feature branches and pull request. Merge all changes from main branch, select final commit, update remote branch, merge pull request, and remove feature branch *
ReleaseMerge features into main branch. Cherry-pick from fix into release branch. No tagging. * * *
SemVerBased on GitFlow. Specifies how to use semantic versioning to tag releases, particularly when the application has multiple “live” states *
SFMLMain branch for active development. Feature and bugfix branches used with naming conventions. Pull requests for code integration. Release tagging. Uses backporting *
Simple GitMain branch is product line. Rebase commits from main branch into change branch to keep up to date and solve conflicts as soon as possible*
Simple Git branchRelies on branching to organise work and damage control, and uses main for integration and deployment *
Simple Git for engineersMain branch for production. Dev branch for integration and prepare releases. Feature and hotfix branches to organise work and patching. Tagging on the main branch. Aimed for continuous integration *
Simple Git for GitHub beginnersRelies on GitHub functionality and user inteface. Clone central repository, pull main branch, create and work on local branch, push and delete local branch *
Skullcandy’sQuality assurance is performed on a dedicated branch. Relies on issue tracking*
Small teamsThe main branch is used for integration and deployment. Local development on a cloned repository. Optional use of feature branches *
Stable mainlineBased on GitFlow. Aimed for continuous integration. The main branch is always stable. Uses standard and patch releases. Rebasing for code integration. Always use fast-forward merges *
Stash Team FlowVariation of GitFlow workflow removing the main branch keeps and uses release branches
instead. Cascades fixes to previous releases
Three-FlowMain, candidate and release branches. Work together if sharing codebase. Rebase commits from the change branch into the main branch. Uses feature toggles.*
Trello AndroidBased on Three-Flow. Recommends short-lived feature branches. Uses merging between branches instead of force pushes. Not for continuous deployment *
Trunk-based development (TBD)All work on a single open branch. Enforceable code style with fast iterations and no usage of pull requests.* *
VICBased on GitFlow. Includes support branches for specific modifications. Proprietary naming conventions for branch creation. Usage of permissions to limit user access to working repositories *
WunderFlowFeatures branched off of master, develop for testing and reviewing, and production for installed code. Development uses features, epic features (bigger project), hotfix, and release branches*

Please contact us if you have information about additional workflows that we could include in the catalogue, or would be interested in helping us to extend the workflows that are defined in our framework.