Branching and Version Control: Difference between revisions
Jump to navigation
Jump to search
| Line 7: | Line 7: | ||
A few considerations should be kept in mind: | 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 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 | * We are a very small core team. | ||
* However, we | * 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. | * Our needs vary depending on whether we are in feature development phases or release and stabilization phases. | ||
| Line 21: | Line 21: | ||
(lives for weeks, (short, merges fast) | (lives for weeks, (short, merges fast) | ||
synced regularly) | 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. | |||
Revision as of 10:59, 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 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.