Git Branching Models: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 8: | Line 8: | ||
* A version branch e.g. ''1.5.2'' is created when releasing a new stable version | * 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) | * 'Stable commits' are merged from ''master'' frequently (==> rolling release like) | ||
* We'd need something like http://i.imgur.com/sAWIOel.png | |||
===== Pros ===== | ===== Pros ===== | ||
| Line 22: | Line 23: | ||
* Release intervals are smaller | * Release intervals are smaller | ||
=== Example | ==== Feature Branches Example ==== | ||
* Current version is 1.5 | * Current version is 1.5 | ||
| Line 42: | Line 43: | ||
==== Cons ==== | ==== Cons ==== | ||
* We have to modify our nightly system and build server settings to support feature branches somehow (required for properly distributing tests) | * We have to modify our nightly system and build server settings to support feature branches somehow (required for properly distributing tests) | ||
** We could probably use Travis CI and AppVeyor to easily maintain public builds for feature branches [[User:Sbx320|Sbx320]] ([[User talk:Sbx320|talk]]) 18:33, 9 August 2016 (UTC) | |||
== 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) | * 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) | ||
** I don't think so: I'd rather think it removes bureucracy as we don't have to cherry-pick commits to 1.5.x any longer and lose track of merged/unmerged commits --[[User:Jusonex|Jusonex]] ([[User talk:Jusonex|talk]]) 16:55, 5 September 2016 (UTC+2) | |||
Latest revision as of 14:55, 5 September 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)
- We'd need something like http://i.imgur.com/sAWIOel.png
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
Feature Branches Example
- Current version is 1.5
- Someone wants to implement complicated things which are netcode-incompatible with 1.5
- Someone creates feature/complicated-things branched from master
- Work is now done on feature/complicated-things
- Once feature/complicated-things is ready it needs to wait for 1.6
- (time passes)
- (1.6 is ready for release)
- master is tagged as 1.5.x-final marking the end of 1.5 compatibility
- master version number is increased to 1.6
- feature/complicated-things is merged into master
- master build gets released to the public
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)