Git Branching Models: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 30: | Line 30: | ||
== Comments == | == Comments == | ||
* My concerns over Feature Branches are largely based upon any added bureaucracy or complexity to making contributions. --[[User:Talidan|Talidan]] ([[User talk:Talidan|talk]]) 18:04, 9 August 2016 (UTC) |
Revision as of 18:04, 9 August 2016
Our current branching model is not optimal and makes keeping track of versions hard. This page discusses various branching models.
Models
Current SVN-like Model
- master is the development branch which contains incompatible code as well
- A version branch e.g. 1.5.2 is created when releasing a new stable version
- 'Stable commits' are merged from master frequently (==> rolling release like)
Pros
- Easy management of incompatible code (==> rolling-release works well)
Cons
- Prone to losing track of differences between master and version branches
- Doesn't integrate well with popular Git models implemented on e.g. GitHub
Feature Branches
- New, maybe incompatible features are implemented in separate branches and merged as soon as they are stable
- master is mostly stable
- When releasing a new version, a tag is created from master
- Release intervals are smaller
Pros
- "Git"-way (==> integrates well with GitHub)
- No weird cherry-picking is necessary
Cons
- We have to modify our nightly system and build server settings to support feature branches somehow (required for properly distributing tests)