Branching and Version Control: Difference between revisions
Jump to navigation
Jump to search
| Line 6: | Line 6: | ||
A few considerations should be kept in mind: | A few considerations should be kept in mind: | ||
* We are a very small core team. | * We are a very small core team. | ||
* However, we want to be able to welcome occasional contributors. | * However, we want to be able to welcome occasional contributors. | ||
| Line 25: | Line 24: | ||
Rules of thumb: | Rules of thumb: | ||
* main is always deployable/stable | * <code>main</code> is always deployable/stable: | ||
** never push straight to it. | |||
** never rewrite history | |||
* Every piece of work gets a short-lived branch: feature/login-form, fix/cart-bug, chore/upgrade-deps. | * 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. | * 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. | * Delete branches after merge to keep things tidy. | ||
Revision as of 11:03, 30 August 2026
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:
mainis always deployable/stable:- never push straight to it.
- never rewrite history
- 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.