Mastering Git Branching: Git Flow, Trunk‑Based Development, and the Omega Model

Today we discuss Git branching strategies.

Git Flow

Git Flow, proposed in 2010, is a classic branching model still widely used after nearly a decade.

It classifies branches by function:

master: the main branch containing the latest stable code, always deployable.

develop: the development branch created from master at project start, containing completed features but not guaranteed to be deployable.

release: created from develop when all features for an iteration are finished; it holds only bug‑fixes for that release and is deleted after merging into master.

feature/*: independent feature branches created from develop; they are merged back into develop once development is complete.

hotfix/*: bug‑fix branches created from master for urgent fixes; after fixing, they are merged into both master and develop.

The necessity of each branch is analyzed:

master

The role of master is consistent across models: it always holds deployable code.

develop

Without a develop branch, all new code would have to be merged directly into master after full testing, limiting flexibility and increasing integration cost.

Having develop isolates feature work from master, allowing features to be merged into develop first and only integrated into master via a release branch.

release

The release branch solves the same problem as develop: it isolates the current release from ongoing development, ensuring that new code does not affect the features slated for the upcoming release.

However, Git Flow has drawbacks, especially for fast‑moving internet companies where iteration cycles are measured in days.

Feature branches may become stale if they cannot be merged quickly into develop.

Maintaining a release branch can cost more than the benefits when features are deployed within a week.

If a feature merged into develop cannot be released immediately, it blocks subsequent features, leading teams to consider cherry‑picking from develop to master, which widens the divergence between the two branches.

Trunk Based Development

This simple model uses only two branches: master (the trunk) and release. All commits go to master; a release branch is created only when a set of features is ready.

Bug fixes on a release are made on master and cherry‑picked back to the release branch.

Originally popular in the SVN era, this approach works well for companies with rapid iteration, allowing small feature branches that are merged back to master within days.

Stability of master is ensured through feature flags or A/B testing.

(Advertisement: the underlying platform provides Apollo and AB services to support these needs.)

All new features are protected by feature flags, enabling safe deployment even for unplanned releases.

While this model supports multiple daily deployments, it trades off some service quality.

Feature flags are not 100% safe.

Cherry‑picking incurs maintenance cost and loses the full context of a release.

A Flexible Hybrid Model

Is there a branching model that combines fast iteration with release safety?

Our Omega system merges the strengths of Git Flow and trunk‑based development:

No traditional develop branch; all feature branches are created from master.

When a release cycle starts, a release branch is cut from master and the selected feature branches are merged into it.

If a feature is dropped during the cycle, the entire release branch is discarded and a new one is created from master with only the desired features.

After testing, the release branch is deployed and then merged back into master.

This model solves the shortcomings of the previous two:

Only master persists; other branches are deleted after their lifecycle, reducing integration overhead.

Feature releases are flexible and reliable; unwanted features can be excluded without polluting the main line.

However, it introduces complex manual operations and maintenance costs, such as careful merging steps, remembering to merge release back to master, and enforcing naming conventions.

Our Omega continuous‑delivery platform automates or semi‑automates these tasks, though some conflict resolution still requires human intervention.

Further detailed documentation will be released on our public account and wiki.

The Omega platform is expected to be available in July; stay tuned!