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

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

2012-03-24T19:42:29Z

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

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

2012-03-24T19:17:25Z

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

Neverendingo: Text replace - "`" to ""`


2011-06-29T21:08:20Z
Text replace - "<code lang="bash">" to "<syntaxhighlight lang="bash">"

				
				
				
				
			
			← Older revision
			Revision as of 21:08, 29 June 2011
			
Line 29:
Line 29:
    
  =====The Recipe=====   =====The Recipe=====
− <code lang="bash">git clone kde:kdelibs + <syntaxhighlight lang="bash">git clone kde:kdelibs
  git remote add integration kde:clones/kdelibs/dafre/kdelibs-integration   git remote add integration kde:clones/kdelibs/dafre/kdelibs-integration
  git fetch integration</syntaxhighlight>   git fetch integration</syntaxhighlight>
Line 37:
Line 37:
  To clone the repository, issue   To clone the repository, issue
    
− <code lang="bash">git clone kde:kdelibs</syntaxhighlight> + <syntaxhighlight lang="bash">git clone kde:kdelibs</syntaxhighlight>
    
  This will create a kdelibs directory containing the whole repository. You now need to add a separate remote for handling ''integration''. A remote is a repository URL, and your local clone can contain multiple repositories to track different branches. To add kdelibs' ''integration'' repository, issue inside kdelibs' clone:   This will create a kdelibs directory containing the whole repository. You now need to add a separate remote for handling ''integration''. A remote is a repository URL, and your local clone can contain multiple repositories to track different branches. To add kdelibs' ''integration'' repository, issue inside kdelibs' clone:
    
− <code lang="bash">git remote add integration kde:clones/kdelibs/dafre/kdelibs-integration</syntaxhighlight> + <syntaxhighlight lang="bash">git remote add integration kde:clones/kdelibs/dafre/kdelibs-integration</syntaxhighlight>
    
  Now, fetch from integration to retrieve the changes:   Now, fetch from integration to retrieve the changes:
    
− <code lang="bash">git fetch integration</syntaxhighlight> + <syntaxhighlight lang="bash">git fetch integration</syntaxhighlight>
    
  {{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 }}

`Neverendingo: Text replace - "`" to ""

2011-06-29T20:51:43Z

Text replace - "</code>" to "</syntaxhighlight>"

Drf at 22:49, 27 April 2011

2011-04-27T22:49:48Z

Aseigo: /* The Recipe */

2011-04-27T18:30:50Z

‎The Recipe

Aseigo: /* Cloning the repository and adding integration */

2011-04-27T18:30:40Z

‎Cloning the repository and adding integration

Aseigo: /* Setting up the development environment */

2011-04-27T18:27:53Z

‎Setting up the development environment

Aseigo: /* Rationale */

2011-04-27T18:26:17Z

‎Rationale

Aseigo at 18:22, 27 April 2011

2011-04-27T18:22:43Z

@@ Line 78: / Line 78: @@
 When you create a branch (like you did), you are not receiving incremental updates from other people working in the repository (so in the ''master'' branch). This is usually not an issue, and instead an advantage: you can work on your code without being affected by other changes.
-However, there are some cases in which ''synchronizing'' your code with what's been going on with master is required. Git gives you two ways for doing that: merging or rebasing. Both have upsides and downsides, and both come at a cost.
+However, there are some cases in which ''synchronizing'' your code with what's been going on with master is required. Git gives you two ways for doing that: merging or rebasing.
-For this reason, you are ''strongly'' invited to avoid merging or rebasing on top of master while developing your feature whenever possible. Although, if you need to, you are supposed to merge your branch with master, and not to rebase it. What you need to do is the following:
+When you are working on a separate branch, you always want to merge instead of rebasing, which should be done only at the end of the branch's lifecycle. A merge can be performed with:
   git fetch --all
   git merge integration/master
-This command merges your work with the very latest code from ''integration/master''. This process comes with a cost: your branch will not be a candidate for a clean rebase, and each merge makes the history more complex.
+This command merges your work with the very latest code from ''integration/master''. Please note that you must merge '''only''' the branch you originated from (integration/master) into your repository: merging a different branch corrupts history and might prevent rebases to succeed.
-−
-Again, this means that you should try to avoid this process if possible, and if you ''absolutely'' need to do that, you should try and keep the number of merges you'll do in your branch as low as possible. More than 3 merges start to create a very cluttered history.
 To learn more about merging, rebasing, and what this implies to your branch and to our merge strategy, you are invited to read [[Development/Tutorials/Git/Feature_Development_Workflow/Rebase_vs_Merge|Rebasing vs. merging: why and how]]

@@ Line 22: / Line 22: @@
 ===Setting up the development environment===
-In the following steps, we will assume your system is set up as shown in the [http://community.kde.org/Sysadmin/GitKdeOrgManual git.kde.org user manual], especially regarding  [http://community.kde.org/Sysadmin/GitKdeOrgManual#Let_Git_rewrite_URL_prefixes automatic URL rewriting for KDE repositories] enabled.
+The following steps assume your system is set up as shown in the [http://community.kde.org/Sysadmin/GitKdeOrgManual git.kde.org user manual], especially regarding  [http://community.kde.org/Sysadmin/GitKdeOrgManual#Let_Git_rewrite_URL_prefixes automatic URL rewriting for KDE repositories] enabled.
 In the following tutorial, we'll refer to kdelibs as the main target, but this applies to any other repository using this policy.

@@ Line 17: / Line 17: @@
 ===Rationale===
-This approach is meant to implement proper quality evaluation into the main repositories, still allowing developers to work on anything they want, and providing a sane merging strategy which does not require any specific knowledge from the developer's side.
+The approach described in this document helps us implement proper quality evaluation for code that ends up in the main repositories while still allowing developers to work on anything they want. It provides a sane merging strategy which does not require any special git knowledge from the contributing developer's side.
 To learn more about the rationale behind this approach, please read [[Development/Tutorials/Git/Feature_Development_Workflow/Rationale|the Rationale article]].

@@ 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. }}
-This tutorial is aimed to get casual developers or developers with limited git knowledge started for developing their own branches, and get them merged and integrated.
+This tutorial can help casual developers as well as developers with a limited knowledge of git to get started quickly. It covers the entire work flow, from developing in branches to getting them merged and integrated for the next release.
 This tutorial does not require any git-specific knowledge.