Git Branching Models: Difference between revisions

From Multi Theft Auto: Wiki
Jump to navigation Jump to search
No edit summary
 
(6 intermediate revisions by 3 users not shown)
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.
Line 7: 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 20: Line 22:
* When releasing a new version, a tag is created from master
* When releasing a new version, a tag is created from master
* Release intervals are smaller
* 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 ====
==== Pros ====
Line 27: 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 ==
TODO
* 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)
    • We could probably use Travis CI and AppVeyor to easily maintain public builds for feature branches Sbx320 (talk) 18:33, 9 August 2016 (UTC)

Comments

  • My concerns over Feature Branches are largely based upon any added bureaucracy or complexity to making contributions. --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 --Jusonex (talk) 16:55, 5 September 2016 (UTC+2)