Development/Tutorials/Git/Feature Development Workflow - Revision history

AnneW: moved Archive:Development/Tutorials/Git/Feature Development Workflow to Development/Tutorials/Git/Feature Development Workflow: revert

2012-03-24T19:44:19Z

moved Archive:Development/Tutorials/Git/Feature Development Workflow to Development/Tutorials/Git/Feature Development Workflow: revert

AnneW: moved Development/Tutorials/Git/Feature Development Workflow to Archive:Development/Tutorials/Git/Feature Development Workflow

2012-03-24T19:17:25Z

moved Development/Tutorials/Git/Feature Development Workflow to Archive:Development/Tutorials/Git/Feature Development Workflow

Aseigo: /* Requirements */

2011-05-19T08:52:29Z

‎Requirements

Aseigo: /* Rationale */

2011-05-19T07:12:35Z

‎Rationale

Drf at 15:37, 28 April 2011

2011-04-28T15:37:38Z

Drf at 15:32, 28 April 2011

2011-04-28T15:32:47Z

Drf at 15:30, 28 April 2011

2011-04-28T15:30:44Z

Drf at 17:49, 27 April 2011

2011-04-27T17:49:50Z

Drf at 14:50, 27 April 2011

2011-04-27T14:50:01Z

Drf at 14:30, 27 April 2011

2011-04-27T14:30:37Z

@@ Line 31: / Line 31: @@
 ===Requirements===
-The requirements of the KDE community that this workflow aims to meet include:
+The requirements of the KDE community that this workflow aims to meet include the following items. The final workflow may not meet all of the requirements with 100% perfection and there may be some need for compromise on some points as we develop the workflow further. However, these are points of value to the KDE community which need to be addressed by the proposed git workflow:
 * master being in a continuously stable state
 * the ability to do integration in a branch other than master
@@ Line 38: / Line 39: @@
 * no interruption to feature development, even during freezes in preparation of Software Compilation releases
 * a single workflow applied across all participants in the Software Compilation and, hopefully, even wider across projects hosted in KDE's git installation to keep the barrier to participation low
+* as clean a history in the repo as possible
 ===Rationale===

@@ Line 29: / Line 29: @@
 * kde-runtime
 * kdelibs (plasma only)
 ===Rationale===

@@ Line 16: / Line 16: @@
 * [[Development/Tutorials/Git/Feature_Development_Workflow/Staging_Phase_Explained|The staging phase explained]]
 * Merge strategies to and from integration
-* Branches and commit policies
+* [[Development/Tutorials/Git/Feature_Development_Workflow/Branches_and_Commit_policies|Branches and commit policies]]

@@ Line 5: / Line 5: @@
 Such policies vary depending on the developer's role inside the project. Please follow the tutorial which best suits your role and profile
-* Casual Developer - follow this tutorial if you simply wish to contribute features or fixes OR you are a developer without specific knowledge of git. Difficulty level: easy
+* [[Development/Tutorials/Git/Feature_Development_Workflow/Simple_Branch_Development|Casual Developer]] - follow this tutorial if you simply wish to contribute features or fixes OR you are a developer without specific knowledge of git. Difficulty level: easy
-* Core Developer with git knowledge - follow this tutorial if you are a developer which contributes frequently AND you have a more-than-average knowledge of git. Difficulty level: manageable
+* [[Development/Tutorials/Git/Feature_Development_Workflow/Branch_Development_With_Merge|Core Developer with git knowledge]] - follow this tutorial if you are a developer which contributes frequently AND you have a more-than-average knowledge of git. Difficulty level: manageable
 * Repository Maintainer - follow this tutorial if you are a repository maintainer or if you want to apply for becoming one. Difficulty level: relevant
@@ Line 16: / Line 16: @@
 * [[Development/Tutorials/Git/Feature_Development_Workflow/Staging_Phase_Explained|The staging phase explained]]
 * Merge strategies to and from integration

@@ Line 11: / Line 11: @@
 Also, for your knowledge, you should check out these specific articles:
-* Which repository should I use?
+* [[Development/Tutorials/Git/Feature_Development_Workflow/Which_repository_should_I_use|Which repository should I use?]]
-* Rationale and explaination of workflow
+* [[Development/Tutorials/Git/Feature_Development_Workflow/Rationale_and_Explanation_of_Workflow|Rationale and explanation of workflow]]
-* Rebasing vs. merging: why and how
+* [[Development/Tutorials/Git/Feature_Development_Workflow/Rebase_vs_Merge|Rebase vs. merging: why and how]]
-* The staging phase explained
+* [[Development/Tutorials/Git/Feature_Development_Workflow/Staging_Phase_Explained|The staging phase explained]]
 * Merge strategies to and from integration

← Older revision		Revision as of 17:49, 27 April 2011
Line 1:		Line 1:
	{{warning\|This page refers to a draft policy which is still to be agreed and implemented. Please take it as a reference for a work in progress project. }}		{{warning\|This page refers to a draft policy which is still to be agreed and implemented. Please take it as a reference for a work in progress project. }}
		+
		+	These tutorials are aimed to get people started with KDE's policy for merging and integrating changes into the repositories.
		+
		+	Such policies vary depending on the developer's role inside the project. Please follow the tutorial which best suits your role and profile
		+
		+	* Casual Developer - follow this tutorial if you simply wish to contribute features or fixes OR you are a developer without specific knowledge of git. Difficulty level: easy
		+	* Core Developer with git knowledge - follow this tutorial if you are a developer which contributes frequently AND you have a more-than-average knowledge of git. Difficulty level: manageable
		+	* Repository Maintainer - follow this tutorial if you are a repository maintainer or if you want to apply for becoming one. Difficulty level: relevant
		+
		+	Also, for your knowledge, you should check out these specific articles:
		+
		+	* Which repository should I use?
		+	* Rationale and explaination of workflow
		+	* Rebasing vs. merging: why and how
		+	* The staging phase explained
		+	* Merge strategies to and from integration
		+
		+
		+

	Some KDE Components have adopted an integration-staging-origin policy for pushing features into KDE's repositories. This document is designed to get developers started with this workflow and understand the steps involved.		Some KDE Components have adopted an integration-staging-origin policy for pushing features into KDE's repositories. This document is designed to get developers started with this workflow and understand the steps involved.

← Older revision		Revision as of 14:50, 27 April 2011
Line 80:		Line 80:

	=====Push your changes to integration=====		=====Push your changes to integration=====
		+	If you have a KDE developer account, simply
		+
		+	git push integration add-hello-button
		+
		+	from within your ''add-hello-button'' branch. If you do not have one, please have your mentor push your branch for you.
		+
		+	=====Submit the branch for review=====
		+	Use Reviewboard for getting your branch reviewed. You can read [http://techbase.kde.org/Development/Review_Board KDE Reviewboard+Git tutorial] for getting started.
		+
		+	====Getting the branch approved====
		+	After your branch has been reviewed and marked as "Ship it!" at least by one of the maintainers of the code you are adding features to, your branch is ready for integration and staging. Your reviewer will inform one of the repository's maintainers of that.
		+
		+	Your work is done at this stage: the maintainer will integrate and stage your branch for you, and will merge it into ''origin'' according to the project's merging policy. You will be CCMailed upon every separate step your branch will take on its way to ''origin/master''

← Older revision		Revision as of 14:30, 27 April 2011
Line 38:		Line 38:

	{{note\|When working with multiple remotes, you can issue ''git fetch --all'' to update all the remotes tracked by your local copy }}		{{note\|When working with multiple remotes, you can issue ''git fetch --all'' to update all the remotes tracked by your local copy }}
		+
		+	====Creating branches====
		+	You now need to get your branches set up, in particular ''integration/master''. In this example, we are creating a new branch named ''integration-master'' which would serve for this purpose in particular:
		+
		+	git checkout -b integration-master integration/master
		+
		+	This command creates a local branch set to track a remote one. This branch should be the branch you'll be basing your work upon: origin/master is not meant for development!
		+
		+	{{note\|Advanced users might want to use ''integration'' as their origin }}
		+
		+	====Using integration vs. using your own clone====
		+	It is ''strongly'' advised to push your work to integration, but under some circumstances (your work is extremely big in size, you do not have a KDE Development account, etc.), it is allowed to push your branches to a separate personal clone. All work should end up into integration for being reviewed anyway.
		+
		+	===Developing a new feature===
		+	We'll now walk through the process needed to develop a new feature. We'll suppose you want to add a button which says "hello" to a specific part of code.
		+
		+	====Creating a new branch====
		+	First thing to do is creating a new branch on which to base your work on. This branch must be based upon ''integration/master''. To make sure this happens, start by issuing
		+
		+	git checkout integration-master
		+
		+	Now create your branch. Give it a self-explainatory name: try to keep branches as atomic as possible, and possibly split big changes throughout multiple branches divided as per topic. In our case, we want to name our branch ''add-hello-button''. To do that, we do:
		+
		+	git checkout -b add-hello-button
		+
		+	That will create our personal branch which is going to contain our work. Push your branch to integration by issuing
		+
		+	git push integration add-hello-button
		+
		+	====Getting the branch reviewed====
		+	Once you are done with your changes, you are ready to get your branch reviewed. This involves three easy steps:
		+
		+	=====Rebase your branch onto integration/master=====
		+	It is important to have your branch rebased to be ready for review. Rebasing puts your commits on top of anything else of the branch you are rebasing on, including the changes from that branch. You of course want to rebase onto ''integration/master''. To do that, issue
		+
		+	git rebase integration/master
		+
		+	Be sure to fetch before doing that. At this stage, conflicts might occur: be sure to fix them and commit/push the result. You will be required to force push at this stage.
		+
		+	{{warning\|Rebasing must be done at this stage only: please avoid rebasing before getting reviewed or after getting reviewed if not strictly necessary }}
		+
		+	=====Push your changes to integration=====