Branching and Version Control

The purpose of this document is to define the rules for branching strategy for LuxCoreRender repositories.

Status: PROPOSAL

Preliminary considerations

A few considerations should be kept in mind:

• We are a very small core team.
• However, we want to be able to welcome occasional contributors.
• Our needs vary depending on whether we are in feature development phases or release and stabilization phases.

Workflow

We rely on a main branch, always stable, always releasable.

main ─────●────●─────────●────●────●──→ (always stable, always releasable)

           \                   \
            feature/big-thing   feature/another-thing
             (lives for weeks,    (short, merges fast)
              synced regularly)

Rules of thumb:

• main is always deployable/stable:
  • Never push straight to it.
  • Never rewrite history
• Releases are represented by tags on the `main` branch
• Every piece of work gets a short-lived branch: feature/login-form, fix/cart-bug, chore/upgrade-deps.
• Keep branches alive for hours to a couple days, not weeks. Long-lived branches are where merge conflicts and "it works on my branch" problems come from.
• Delete branches after merge to keep things tidy.