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 shouldn’t reinvent the wheel. There are enough de facto standards around there (https://dev.to/karmpatel/git-branching-strategies-a-comprehensive-guide-24kh)
• 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.
• 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.