Development/Git/Feature Branch Workflow - Revision history

Odysseus: /* Remote Feature Development */

2011-06-13T17:26:40Z

‎Remote Feature Development

Odysseus: /* Remote Feature Development */

2011-06-13T09:49:11Z

‎Remote Feature Development

Odysseus: /* Local Bug Fixing */

2011-06-13T09:40:36Z

‎Local Bug Fixing

Odysseus: /* Remote Feature Development */

2011-06-13T09:40:12Z

‎Remote Feature Development

Odysseus: /* Making Changes */

2011-06-13T09:29:01Z

‎Making Changes

Odysseus: /* Remote Feature Development */

2011-06-13T08:10:58Z

‎Remote Feature Development

Odysseus: /* Local Bug Fixing */

2011-06-12T21:51:21Z

‎Local Bug Fixing

Odysseus: /* Remote Feature Development */

2011-06-12T21:50:59Z

‎Remote Feature Development

Odysseus: /* Local Bug Fixing */

2011-06-12T21:42:53Z

‎Local Bug Fixing

Odysseus: /* Local Bug Fixing */

2011-06-12T21:42:29Z

‎Local Bug Fixing

@@ Line 98: / Line 98: @@
 TODO Steps:
 * Create the remote branch tracking master
 * Create your local branch tracking the remote branch
 * Do local dev and commits, rebase, push
 * When to use Merges, when to Rebase?

@@ Line 92: / Line 92: @@
 This example workflow is for working on new features in a feature branch hosted on the central repository.  This workflow is recommended for larger features or where there are many developers on a project.
-The main disadvantage of local feature branch development is no-one else can see your code changes or help you until the finished feature is pushed to master on the central repository.  You could resolve this by regularly pushing incomplete features to master, but this will lead to master becoming more unstable.  The proper solution is to create a Remote Feature Branch on the central repository where you can push your interim work for others to see and also push changes.
+The main disadvantage of local feature branch development is no-one else can see your code changes or help you until the finished feature is pushed to master on the central repository.  You could resolve this by regularly pushing incomplete features to master, but this will lead to master becoming more unstable.  The proper solution is to create a Remote Feature Branch on the central repository where you can push your interim work for others to see and also push changes to.
 TODO: Finish this.
 == Local Bug Fixing ==

@@ Line 100: / Line 100: @@
 This example workflow is for locally fixing bugs in both the stable and unstable branches and pushing them to the central repository.
-In Git, stable branches are just regular branches that have special meaning to a project and a possibly a special naming scheme to distinguish them.  For example, kdelibs includes the following branches on the central repository:
+In Git, stable branches are just regular branches that have special meaning to a project and possibly a special naming scheme to distinguish them.  For example, kdelibs includes the following branches on the central repository:
    origin/HEAD -> origin/master

@@ Line 90: / Line 90: @@
 == Remote Feature Development ==
-This example workflow is for working on new features in a feature branch hosted on the central repository.
+This example workflow is for working on new features in a feature branch hosted on the central repository.  This workflow is recommended for larger features or where there are many developers on a project.
-This workflow is recommended for larger features or where there are many developers on a project.
+The main disadvantage of local feature branch development is no-one else can see your code changes or help you until the finished feature is pushed to master on the central repository.  You could resolve this by regularly pushing incomplete features to master, but this will lead to master becoming more unstable.  The proper solution is to create a Remote Feature Branch on the central repository where you can push your interim work for others to see and also push changes.
-−
 The main disadvantage of local feature branch development is no-one else can see your code changes or help you until the finished feature is pushed to the central repository.
 TODO: Finish this.

← Older revision		Revision as of 09:29, 13 June 2011
Line 73:		Line 73:

	You can now make [[Development/Git/Simple_Workflow#Making_Local_Changes_and_Commits\|local changes and commits]], and [[Development/Git/Simple_Workflow#Pushing_Your_Changes_To_The_Central_Repository\|push them to the central repository]] exactly as described in the [[Development/Git/Simple_Workflow\|Simple Workflow]].		You can now make [[Development/Git/Simple_Workflow#Making_Local_Changes_and_Commits\|local changes and commits]], and [[Development/Git/Simple_Workflow#Pushing_Your_Changes_To_The_Central_Repository\|push them to the central repository]] exactly as described in the [[Development/Git/Simple_Workflow\|Simple Workflow]].
		+
		+	Your project may require changes to be reviewed before pushing to the central code repository. All projects on git.kde.org automatically have a [[Development/Review_Board\|Review Board]] group created for them which you can use for this purpose. It is recommended that you use the [[Development/Review_Board#Using_post-review_to_post_changes_for_review\|post-review script]] to automatically generate and upload the diff of your changes.

	=== Deleting Local Branches ===		=== Deleting Local Branches ===

← Older revision		Revision as of 08:10, 13 June 2011
Line 91:		Line 91:

	This workflow is recommended for larger features or where there are many developers on a project.		This workflow is recommended for larger features or where there are many developers on a project.
		+
		+	The main disadvantage of local feature branch development is no-one else can see your code changes or help you until the finished feature is pushed to the central repository.

	TODO: Finish this.		TODO: Finish this.

← Older revision		Revision as of 21:51, 12 June 2011
Line 118:		Line 118:

	A better alternative is to use the [[Development/Git/Configuration#Multiple_Work_Branches\|git-new-workdir script]] to create separate work directories and builds for the stable and unstable branches using the same repository clone. This depends on you setting different up KDE Environments for the separate builds.		A better alternative is to use the [[Development/Git/Configuration#Multiple_Work_Branches\|git-new-workdir script]] to create separate work directories and builds for the stable and unstable branches using the same repository clone. This depends on you setting different up KDE Environments for the separate builds.
		+
		+	TODO: Finish this.

← Older revision		Revision as of 21:50, 12 June 2011
Line 91:		Line 91:

	This workflow is recommended for larger features or where there are many developers on a project.		This workflow is recommended for larger features or where there are many developers on a project.
		+
		+	TODO: Finish this.

	== Local Bug Fixing ==		== Local Bug Fixing ==

← Older revision		Revision as of 21:42, 12 June 2011
Line 115:		Line 115:
	One alternative is to have two separate clones using two separate build environments, but this wastes disk space and causes problems with keeping the separate clones in sync.		One alternative is to have two separate clones using two separate build environments, but this wastes disk space and causes problems with keeping the separate clones in sync.

−	A better alternative is to use the [[~~http://techbase.kde.org/~~Development/Git/Configuration#Multiple_Work_Branches\|git-new-workdir script]] to create separate work directories and builds for the stable and unstable branches using the same repository clone. This depends on you setting different up KDE Environments for the separate builds.	+	A better alternative is to use the [[Development/Git/Configuration#Multiple_Work_Branches\|git-new-workdir script]] to create separate work directories and builds for the stable and unstable branches using the same repository clone. This depends on you setting different up KDE Environments for the separate builds.

← Older revision		Revision as of 21:42, 12 June 2011
Line 113:		Line 113:
	The basic workflow works fine except switching between unstable and stable branches inside a single Git repository can lead to large rebuilds if the unstable branch has diverged too much from the stable branch. On a small app this overhead may be small enough to not be a problem, but in most cases this constant rebuilding will be a waste of time.		The basic workflow works fine except switching between unstable and stable branches inside a single Git repository can lead to large rebuilds if the unstable branch has diverged too much from the stable branch. On a small app this overhead may be small enough to not be a problem, but in most cases this constant rebuilding will be a waste of time.

−	~~This workflow uses~~ the [[http://techbase.kde.org/Development/Git/Configuration#Multiple_Work_Branches\|git-new-workdir script]] to create separate work directories and builds for stable and unstable branches. This depends on you setting different up KDE Environments for the separate builds.	+	One alternative is to have two separate clones using two separate build environments, but this wastes disk space and causes problems with keeping the separate clones in sync.
		+
		+	A better alternative is to use the [[http://techbase.kde.org/Development/Git/Configuration#Multiple_Work_Branches\|git-new-workdir script]] to create separate work directories and builds for the stable and unstable branches using the same repository clone. This depends on you setting different up KDE Environments for the separate builds.