17.2 Branching Approach [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 17.2 Branching Approach ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:17-git-and-review-workflow:start | Return to Git and Review Workflow ]]

The team should use a simple branching approach for Phase 0 unless the project requires a more formal release model. The branching approach should support parallel development, review, Baseline stability, and demonstration preparation without creating unnecessary process overhead.

A practical Phase 0 branching model may include:

  - A protected main branch for accepted Baseline content.
  - Short-lived feature branches for specific changes.
  - Review branches for larger coordinated updates.
  - Release or demonstration branches where the team needs to freeze a specific Baseline.
  - Tags for accepted Phase 0 Baselines, release candidates, or demonstration runs.

Developers should create branches for changes that affect source files, IDL definitions, generated Artifact policy, scripts, Configuration, containers, tests, documentation, or acceptance Evidence. Developers should avoid committing directly to the protected Baseline branch unless the team explicitly permits it.

Branch names should identify the purpose of the change. Representative branch names include:

  * ''feature/control-plane-status-topic''
  * ''feature/generate-types-script''
  * ''fix/container-networking''
  * ''docs/node-catalogue''
  * ''baseline/phase0-demo''

The team should avoid branch names that include personal notes, unclear abbreviations, temporary labels, or editing-history terms such as new, old, final, or backup.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>