In this post I'll introduce very simple software development workflows, each suitable for different needs:
- The "Red Light, Green Light Flow", suitable for occasional releases
- The "Light Flow", suitable for regular releases (weekly/monthly)
- I will also compare them to the GitHub Flow, "GitFlow", and "Trunk Based Development".
The Red Light, Green Light / Feature Freeze Flow
Like in the famous children's game of "Red Light, Green Light" (aka "Statues", and many other names), development switches between two modes:
- Free dev. New features are developed freely and big changes may happen to the codebase, often introducing bugs.
- Preparing to ship, aka "code freeze". At this stage bugs and problems are fixed.
When preparing releases and not deliberately choosing a workflow, work tends to naturally develop into the RLGL flow. When you find that there are too many bugs, it may come naturally to decide: "let's focus on fixing bugs now and keep the new features for later".
The mutex analogy: A freeze is mutually exclusive with adding
Challenges with statefulness and concurrency
If you ever heard an "Oh! I wasn't aware that we're in a feature freeze", that's because communication is tricky. Someone may have missed a meeting, or announcements in the group chat may have been drowned by other messages. If you find coordinating the state to be tricky, it may make sense to use a flow that formalizes the modes of development in the structure of the git branches.
The Light Flow
The different types of branches and commits in the diagram:
- The main branch in the middle is colored in yellow
- Feature branches are colored purple. They are surrounded by dashes
to signify that they are temporary: some might be aborted, others will
be rebased and will ultimately become normal commits in
- Release branches are colored in green. They end up with a release
and are merged into
- Releases, given
git tags, are displayed as rectangular nodes
How to Light Flow
- Developers can freely add new features to
mainat all times!
- A bug tracker is used to keep track of tasks
- A list of known bugs that shouldn't be in a release is maintained
- A list of fresh and not yet well tested features in the
mainbranch is also maintained
- For each bug or feature, the commit which introduced it is identified in its issue
- Bugfix commits should mention which bugs were fixed
- Preparing a release
- If the
mainbranch happens to be in a good bug-free state, then we're in luck, and just
git tagit as a release candidate!
- If we still have bugs to fix for the release, then we open a release branch
- If the
Using a release branch
main branch is not suitable for release as is,
the person in charge of the release will create a branch from a selected
main, calling it
informally "the current release branch".
- Bug fixes are added to the release branch
- Once the known bugs appear to be fixed, tag and build a release candidate
- If new issues are discovered in the RC, go back to the previous stage
- When the RC is good: ship the release, tag it, and merge the branch
main. Merge it - don't rebase, so that the actual release is in
How to choose a branching point for the release branch
The commit messages and the bug tracker help us "taint" the states in
main branch with existence of various bugs.
- Unfixed bugs taint
mainsince they were introduced
- Bugs that were fixed taint only a specific range of commits
A good point to start the release branch is one which is relatively clean, yet also includes valueable features which improve upon the previous release.
If the chosen point doesn't include all the fixes currently available
git cherry-pick them into the
Caution with reverts on the release branch
Sometimes we may want to
git revert a commit only for a
release branch. In this case we should keep in mind that if we merge the
release branch as is, the revert will propagate into
If we wish to avoid that, we should remember to un-revert the
How does Light Flow compare to other workflows
The GitHub Flow
Flow has a
main branch and feature branches, without
Its tools to avoid bugs are code reviews for all changes and rolling back faulty versions. If you can un-deploy faulty versions, which is often possible for web apps, and can put in the time and effort to do good code review, then this flow might work well for you.
If you prefer to avoid faulty releases, and prefer to not extensively code review each and every change, then the Light Flow is probably a better fit.
Comparison to GitFlow
Note that Vincent Driessen, the creator of GitFlow, currently recommends most projects to adopt the GitHub Flow instead.
The Light flow is a simplified variant of GitFlow. The differences are:
- An additional
masterbranch points to the latest release
- GitFlow suggests to use explicit merge commits when merging feature branches, while the Light Flow recommends rebases
- GitFlow explicitly describes a process for hotfix branches, which branch out of previous releases and add fixes to them. This makes sense for projects which maintain multiple versions. This may happen if new versions of the product are paid upgrades but old version still get bug fixes. For such projects GitFlow is probably a very good choice.
The Light Flow's recommendation for rebasing feature branches and
omission of hotfix branches puts an emphasis on integrating new
developments faster and releasing them from
often, to avoid accumulating a gap of unreleased and unstable
Comparison to Trunk Based Development
The Trunk Based
Development may seem similar to the light flow, as the difference is
small: It prescribes that release branches should not
be merged back to
Its site refers to the Light Flow by the name "Mainline" (note that their description predates this post), and it considers it as the "diametrically opposite to Trunk-Based Development", and furthermore, recommends not to use it! But personally I'm not convinced, and I'll demonstrate with a simple example how the small difference between workflow affects things:
Imagine that we decided to revert a commit in a release branch.
The following diagram represents the diff between Light Flow and
Trunk based in this scenario, in the form of a bright pink cherry-pick
commit and pink arrows denoting merges of release branches back to
git log release-2.4..release2.5 in this example
would list the correct changes list of changes between these releases
with the Light Flow, but using Trunk-Based it will be have a misleading
result for this log that omits the re-introduction of the reverted
Does the Light Flow work
I wrote this post in order to suggest this model for the development of Pajam (btw, if you happen to be a musician that wants to jam with their friends remotely, I highly recommend you to give Pajam a try!).
Update from 2021.01.26: So far this flow is working very well for us!
- Discussion on r/programming
- Image credits:
- Title image (merging neutron stars): University of Warwick/Mark Garlick
- GitFlow: Vincent Driessen
- The Light Flow Diagram's colors are inspired by the diagram for GitFlow, and were specifically chosen to be consistent with it for easy comparison
- 2020.11.16: Comparison with "Trunk Based Development"