Git Branching Models: Difference between revisions

From Multi Theft Auto: Wiki
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 (adding a big feature) ===
==== 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)
    • 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)