> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/techniques/source-code-management/branching-model.md).

# Branching Model

flxbl projects follow [Trunk Based Development](https://trunkbaseddevelopment.com/). Developers work on short-lived feature branches, open a pull request, and — once validation passes and reviewers are happy — merge into the trunk, the `main` branch. Because flxbl uses an artifact-based deployment model, branches are delinked from production: each merge produces a release candidate, a versioned collection of artifacts, and that artifact is what gets deployed — not the branch.

<figure><img src="/files/AU1VZtqHcG0R3RD6XAiE" alt=""><figcaption><p>Trunk based development with a release candidate generated on every merge</p></figcaption></figure>

## How it works

A developer works on a small piece of functionality on a short-lived feature branch. When it is ready, they raise a pull request to integrate it into `main`. codev validates the change against a real org before it merges, and once reviewers approve, it merges immediately.

Each merge into `main` creates a release candidate for the impacted domain, deployable to production. A release candidate is a collection of artifacts and an associated version number, generated at every commit on the trunk — defined by a [release definition](https://docs.flxbl.io/sfp/releasing-artifacts/release-definitions) and built automatically by [codev on merge](https://docs.flxbl.io/codev/builds/overview). The branch the work happened on plays no further part; the artifact is the unit of deployment.

{% hint style="success" %}
flxbl recommends the ship / show / ask pattern for pull requests to keep throughput high. See [ship/show/ask](https://martinfowler.com/articles/ship-show-ask.html).
{% endhint %}

## Scaling to multiple release lines

Most teams need only the trunk. When you have to support more than one release line at once — a long-running `release/*` branch alongside `main`, for instance to stabilise a release while the trunk moves on — flxbl scales to Scaled Trunk Based Development without changing the model.

codev treats a release branch like the trunk. Merges to a `release/*` branch [build and validate](https://docs.flxbl.io/codev/builds/overview) the same way and produce their own release candidates. You can [bind an environment to `release/*`](https://docs.flxbl.io/codev/builds/overview#deploying-to-environments-by-branch) so those builds deploy to it, and a [cascade](https://docs.flxbl.io/codev/ci-cd/cascades) keeps the release branch and the trunk from drifting apart by opening and merging the integration pull requests automatically. If your team does not deploy continuously, or works in a single domain, the same machinery supports a [branch-for-release](https://trunkbaseddevelopment.com/branch-for-release/) approach.

## Applying patches and hotfixes

{% hint style="info" %}
High-throughput flxbl projects should prefer a roll-forward strategy over patching an existing release.
{% endhint %}

Because a flxbl project runs on multiple independently deployable domains, a patch or hotfix is scoped to a domain. codev creates a just-in-time release branch from the exact state of a release candidate — a temporary branch holding the artifacts that make up what is currently in production — applies the fix there, builds new artifacts, and deploys them. The fix is then propagated back into the trunk.

{% embed url="<https://docs.google.com/presentation/d/e/2PACX-1vQgwJ-xm3dtvXpjc7QxsowxCDz5B7bxNFIVTnVkeNiyKLTiQ-RRcV8DRh1z7n5LjdRnrdTyy55Os0Sc/pub?start=false&loop=false&delayms=3000>" %}

codev runs this from the **Patch** action on a release candidate; sfp-pro is the engine underneath. See [Patch a release candidate](https://docs.flxbl.io/codev/release-candidates/managing-release-candidates#patch).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.flxbl.io/flxbl/techniques/source-code-management/branching-model.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.