Git Branching Models: Difference between revisions
Jump to navigation
Jump to search
(Created page with "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 ===...") |
No edit summary |
||
| Line 4: | Line 4: | ||
== Models == | == Models == | ||
=== Current SVN-like Model === | === 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 ===== | ===== Pros ===== | ||
* Easy management of incompatible code (==> rolling-release works well) | * Easy management of incompatible code (==> rolling-release works well) | ||
| Line 11: | Line 15: | ||
* Doesn't integrate well with popular Git models implemented on e.g. GitHub | * 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 == | == Comments == | ||
TODO | TODO | ||
Revision as of 17:50, 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