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 team. System adapted to large teams may not be relevant for us | * We are a very small core team. System adapted to large teams may not be relevant for us. | ||
* However, we should 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. | ||
Revision as of 08:02, 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. System adapted to large teams may not be relevant for us.
- However, we should 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)