Git Branching Models: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
__NOTOC__ | |||
Our current branching model is not optimal and makes keeping track of versions hard. | Our current branching model is not optimal and makes keeping track of versions hard. | ||
This page discusses various branching models. | This page discusses various branching models. |
Revision as of 17:51, 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)
Comments
TODO