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.
| Workflow | Summary | Sources |
|---|---|---|
| Backcountry | All development in main. Release and change branch off from main and must be merged back. | * |
| BioGitFlow | Based on GitFlow and using GitLab. Focused on the development of new features and hotfixes. | * |
| BitBucket | Production and staging development lines. New versions from staging to production through pull requests except hotfixes. Other workflows allowed on the platform. | * |
| BOINC Flow | The 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 model | All development in main branch. Change branches do not get merged back into master. Rebase commits instead. Cherry-pick from fix branches. | * |
| Centralized | All commits applied to the main branch. | * * * * * |
| Compartmentalise | Based 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 model | Based 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 reviews | Variation of FB workflow that uses pull requests to perform code reviews before merging | * |
| Fork | Developers with own forked repository, push changes first to local, maintainer integrates | * * * |
| Fork & branch | Designed 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 branches | Recommends the creation of a local repository to work on dedicated feature branches to maintain a clean central repository | * |
| Gentoo | The 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 Common | All commits on change branches, rebasing commits into main branch. | * |
| Git Merge | Relies on merging for code integration | * |
| Git Rebase | Relies on rebasing for code integration | * |
| GitFlow | Parallel development using develop branch. Uses release and fix branches. | * * * * * * |
| GitHub | Main branch always deployable. Intensive use of pull requests. | * * * |
| GitLab | Feature-driven development with change branches and issue tracking. Upstream-first policy. | * * * |
| GitWaterFlow | Inspired 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 Flow | Designed for the development of health-related software. Uses change and release branches. | * |
| Maintenance | For hotfixes. Branches off from main and merges back into main and development branches | * |
| Mantid | Based on GitHub Flow. Specifies naming conventions for branch creation. Enforces testing and the usage of pull requests for code integration | * |
| MojoTech | The main branch is always in a ready-state. Rebasing and pull requests are encouraged. Naming convention for feature branches | * |
| MuseScore | Fork and clone to setup the working repository. Uses issue branches for work. Fetch from origin, rebase and push updated branch | * |
| OneFlow | Single long-lived main with short-lived change, release and fix branches. Accumulative releases. | * * |
| Open Source Repositories | Clone 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 | * |
| PLEFlow | Uses two branching models to work at product and variant levels. | * |
| Practical | Create 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 | * |
| Professional | Track 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 | * |
| Release | Merge features into main branch. Cherry-pick from fix into release branch. No tagging. | * * * |
| SemVer | Based on GitFlow. Specifies how to use semantic versioning to tag releases, particularly when the application has multiple “live” states | * |
| SFML | Main branch for active development. Feature and bugfix branches used with naming conventions. Pull requests for code integration. Release tagging. Uses backporting | * |
| Simple Git | Main 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 branch | Relies on branching to organise work and damage control, and uses main for integration and deployment | * |
| Simple Git for engineers | Main 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 beginners | Relies on GitHub functionality and user inteface. Clone central repository, pull main branch, create and work on local branch, push and delete local branch | * |
| Skullcandy’s | Quality assurance is performed on a dedicated branch. Relies on issue tracking | * |
| Small teams | The main branch is used for integration and deployment. Local development on a cloned repository. Optional use of feature branches | * |
| Stable mainline | Based 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 Flow | Variation of GitFlow workflow removing the main branch keeps and uses release branches instead. Cascades fixes to previous releases | * |
| Three-Flow | Main, candidate and release branches. Work together if sharing codebase. Rebase commits from the change branch into the main branch. Uses feature toggles. | * |
| Trello Android | Based 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. | * * |
| VIC | Based on GitFlow. Includes support branches for specific modifications. Proprietary naming conventions for branch creation. Usage of permissions to limit user access to working repositories | * |
| WunderFlow | Features 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.