Git Branching Models - Revision history

Jusonex: /* Comments */

2016-09-05T14:55:03Z

Comments

← Older revision		Revision as of 14:55, 5 September 2016
Line 47:		Line 47:
	== 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)

Jusonex at 16:02, 11 August 2016

2016-08-11T16:02:54Z

← Older revision		Revision as of 16:02, 11 August 2016
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 =====

Jusonex at 19:19, 9 August 2016

2016-08-09T19:19:37Z

← Older revision		Revision as of 19:19, 9 August 2016
Line 22:		Line 22:
	* Release intervals are smaller		* Release intervals are smaller

	=== Feature Branches Example ===		==== Feature Branches Example ====

	* Current version is 1.5		* Current version is 1.5

Sbx320 at 18:33, 9 August 2016

2016-08-09T18:33:43Z

← Older revision		Revision as of 18:33, 9 August 2016
Line 22:		Line 22:
	* 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 42:
	==== 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)

Sbx320 at 18:30, 9 August 2016

2016-08-09T18:30:10Z

@@ Line 21: / Line 21: @@
 * When releasing a new version, a tag is created from master
 * Release intervals are smaller
 ==== Pros ====

Talidan: /* Comments */

2016-08-09T18:04:56Z

Comments

← Older revision		Revision as of 18:04, 9 August 2016
Line 30:		Line 30:

	== 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)

Jusonex at 17:51, 9 August 2016

2016-08-09T17:51:48Z

← Older revision		Revision as of 17:51, 9 August 2016
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.

Jusonex at 17:50, 9 August 2016

2016-08-09T17:50:47Z

← Older revision		Revision as of 17:50, 9 August 2016
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

	=== ~~TODO~~ ===		=== Feature Branches ===
	~~TODO~~		* 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

Jusonex: 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 ===..."

2016-08-09T17:24:13Z

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 ===..."

New page

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 ===
===== 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

=== TODO ===
TODO

== Comments ==
TODO