Branches — Working in Parallel

How developers work on new features without risking the stable version of the project.

What is a branch?

A branch is like making a photocopy of a document to try edits on. You take the original report, photocopy it, and start rewriting the introduction on the copy. Meanwhile, the original stays safe on your desk. If the rewrite works out, you replace the original. If not, you bin the copy. The original was never touched.

In Git, a branch is a separate line of development. It starts as an exact copy of the project, then evolves independently. When the work is ready, it gets merged back into the original.

The main branches

Most projects have two permanent branches:

main

The production version — what is live and running. Think of it as the published edition of a book. Only thoroughly reviewed work goes here.

develop

The integration version — where finished features are collected before release. Think of it as the editor's draft that combines all the approved chapter rewrites.

Feature branches

When a developer starts working on something new, they create a feature branch. This is a temporary branch that exists only while the work is in progress. Feature branches are typically named descriptively:

  • feature/dark-mode — adding a dark mode option
  • feature/mesh-hub-v0.2 — version 0.2 of the Mesh Hub
  • fix/login-crash — fixing a specific bug
  • feature/physics-controls — adding physics simulation controls

How branching works visually

gitGraph commit id: "v1.0 release" branch develop checkout develop commit id: "Setup develop" branch feature/dark-mode checkout feature/dark-mode commit id: "Add toggle" commit id: "Style dark theme" checkout develop merge feature/dark-mode id: "Merge dark mode" branch feature/sidebar checkout feature/sidebar commit id: "Add sidebar nav" commit id: "Responsive layout" checkout develop merge feature/sidebar id: "Merge sidebar" checkout main merge develop id: "Release v1.1"

Two feature branches are created from develop. Each one is worked on independently, then merged back. When develop is stable, it merges into main for release.

The lifecycle of a branch

flowchart LR A["Create branch"] --> B["Make changes"] B --> C["Commit work"] C --> D["Push to GitHub"] D --> E["Open a PR"] E --> F{Approved?} F -->|Yes| G["Merge into develop"] F -->|No| B G --> H["Delete branch"] style A fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0 style B fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0 style C fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0 style D fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0 style E fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0 style F fill:#141a2e,stroke:#ffab40,color:#e0e6f0 style G fill:#1e2a4a,stroke:#00e676,color:#e0e6f0 style H fill:#1e2a4a,stroke:#8892a8,color:#e0e6f0

The life of a feature branch: create it, work on it, get it reviewed, merge it, delete it. If the review finds issues, the developer goes back to make more changes.

When should a branch be created?

New feature

"I want to add a chat sidebar to the app."

Bug fix

"The login button crashes on mobile — I need to fix that."

Experiment

"Let me try a different layout and see if it looks better."

Refactor

"The code works but it is messy — I want to reorganize it."

A good rule: one branch per task. If you are working on two unrelated things, create two branches. This keeps changes isolated and easy to review.

What about merge conflicts?

A merge conflict is like two people editing the same sentence in a shared document. Person A changes "The sky is blue" to "The sky is grey". Person B changes the same sentence to "The sky is orange". Git does not know which version to keep, so it asks a human to decide.

Merge conflicts are normal and not dangerous. They just mean two branches changed the same part of a file, and Git needs a human to choose which version is correct. Developers resolve these routinely.

If a developer mentions "merge conflicts", do not panic. It is a routine part of collaboration, not an error. It simply means two pieces of work overlapped and need a quick decision about which changes to keep.

Real BACON-AI example

The BACON Mesh Hub project currently uses this branching structure:

gitGraph commit id: "Initial scaffold" branch develop checkout develop commit id: "Add WebSocket server" commit id: "Basic mesh UI" branch feature/mesh-hub-v0.2 checkout feature/mesh-hub-v0.2 commit id: "WhatsApp-style input" commit id: "Scroll fixes" checkout develop branch feature/physics-controls checkout feature/physics-controls commit id: "Force layout panel" commit id: "Physics sliders" checkout develop merge feature/mesh-hub-v0.2 id: "Merge v0.2"

Real branches from the BACON Mesh Hub project. The feature/mesh-hub-v0.2 branch added a WhatsApp-style input bar, while feature/physics-controls added physics simulation controls — both developed in parallel.

Key takeaways

Remember:
  • A branch is a safe copy of the project for trying new things.
  • main is the live version; develop is the staging area.
  • Feature branches are temporary — they get merged and deleted.
  • Merge conflicts are normal, not dangerous.