Development/Git/Simple Workflow - Revision history

Fengchao: /* Local Bug Fixing */ Add commit hooks link.

2013-01-08T14:27:35Z

‎Local Bug Fixing: Add commit hooks link.

Rakuco: /* Making Local Changes and Commits */ Mention git add -p

2011-06-14T00:51:18Z

‎Making Local Changes and Commits: Mention git add -p

Odysseus: /* Local Bug Fixing */

2011-06-13T09:34:56Z

‎Local Bug Fixing

Odysseus: /* Local Bug Fixing */

2011-06-13T09:20:07Z

‎Local Bug Fixing

Odysseus: /* Local Bug Fixing */

2011-06-13T09:15:12Z

‎Local Bug Fixing

Odysseus: /* Pushing Your Changes To The Central Repository */

2011-06-13T09:11:02Z

‎Pushing Your Changes To The Central Repository

Odysseus: /* Simple Workflow */

2011-06-12T16:37:24Z

‎Simple Workflow

Odysseus: /* Simple Workflow */

2011-06-12T15:01:35Z

‎Simple Workflow

Odysseus: /* Local Bug Fixing */

2011-06-12T14:58:16Z

‎Local Bug Fixing

Odysseus: /* Local Feature Development */

2011-06-12T14:53:26Z

‎Local Feature Development

@@ Line 196: / Line 196: @@
   git pull --rebase
-Now make your required changes to the code, build and test.  Once done commit the code changes to your local repository, remembering to include the BUG: and FIXED-IN: keywords in the commit message:
+Now make your required changes to the code, build and test.  Once done commit the code changes to your local repository, remembering to include the BUG: and FIXED-IN: [http://community.kde.org/Sysadmin/GitKdeOrgManual#Commit_hook_keywords keywords in the commit message].
   git commit -a

← Older revision		Revision as of 00:51, 14 June 2011
Line 87:		Line 87:

	git add <filename>		git add <filename>
		+
		+	You can also partially add the contents of a file to the staging area, so that it is easier to commit sets of related changes;
		+
		+	git add -p <filename>

	To delete a file from the repository and add the deletion to the staging area:		To delete a file from the repository and add the deletion to the staging area:

@@ Line 160: / Line 160: @@
 If your bug fix is for a stable branch then this cannot be done without using git branches.  The steps required will be given below but not explained in any detail.  If possible it is recommended you wait until you are familiar with using the [[Development/Git/Feature_Branch_Workflow|Feature Branch Workflow]].
-The steps detailed below are very inefficient as they use the same build tree and environment for unstable and stable which may cause a lot of rebuilding.  A more efficient method is detailed in the [[Development/Git/Feature_Branch_Workflow|Feature Branch Workflow]].
+The steps detailed below are very inefficient as they use the same build tree and environment for unstable and stable which may cause a lot of rebuilding.  A more efficient method is detailed in the [[Development/Git/Feature_Branch_Workflow#Local_Bug_Fixing|Feature Branch Workflow]].
 First, find out the name of the stable branch you want to bug fix:

@@ Line 182: / Line 182: @@
   git checkout <local-branch>
-For example, to create a kdelibs 4.6 stable branch:
+For example, to create a local kdelibs 4.6 stable branch:
   git branch --track KDE/4.6 origin/KDE/4.6
@@ Line 199: / Line 199: @@
 Now you can push your changes into the central code repository:
   git pull --rebase
@@ Line 214: / Line 219: @@
 This will allow you to edit the commit message as required before the change is committed.  If the patch does not apply cleanly a message will appear and the changes will not be committed.  You will then have to edit the changes and finish the commit manually.
-Once cleanly applied and committed you can build and test the change, then merge them into the central code repository:
+Once cleanly applied and committed you can build and test the change, then push them to the central code repository:
   git pull --rebase
   git push origin master:master

@@ Line 178: / Line 178: @@
 Next, create a local branch pointing to the stable release branch you want to bug fix:
   git branch --track KDE/4.6 origin/KDE/4.6
@@ Line 184: / Line 189: @@
 If you have previously created the stable branch and want to do a new bug fix, then simply check it out again and update it:
-  git checkout KDE/4.6
+  git checkout <local-branch>
   git pull --rebase

@@ Line 146: / Line 146: @@
 Note that you cannot rebase if you have uncommitted changes.  If you need to rebase but have changes that you don't want to commit, then you will need to [[Development/Git/Recipes#Stashing_Changes|stash the changes]].
-Depending on how much the underlying master code has changed you may want to rebuild and test the code before doing a final rebase.  It is recommended to do regular rebase's between commits to keep the possibility of conflicts to a minimum.
+Depending on how much the underlying master code has changed you may want to rebuild and test the code after doing the rebase, before doing a final rebase.  It is recommended to do regular rebase's between commits to keep the possibility of conflicts to a minimum.
 Once your local commits have been cleanly reapplied you can push your changes to the central repository:

@@ Line 27: / Line 27: @@
   cd <project>
-In our KFoo example:
+For example to clone kdelibs:
-  git clone kde:kfoo
+  git clone kde:kdelibs
-  cd kfoo
+  cd kdelibs
 See the [[Getting_Started/Build/Environment#Source_Path|KDE Build Environment]] page for advice on structuring your source directory.

@@ Line 5: / Line 5: @@
 This workflow is designed to be as close as possible to the KDE SVN Workflow.  It is only recommended to be used for the first week or two of using Git with KDE while you become familiar with the basic Git commands.  Once comfortable with the basic commands you should then move on to the [[Development/Git/Feature_Branch_Workflow|Feature Branch Workflow]].
-In particular this workflow will not use git branches or any remote features, all feature work will be in the local master (the Git name for trunk).
+In particular this workflow will not use git branches, merging or any remote features, all feature development work will be in the local master branch (the Git name for trunk).
-The worked examples given will be for an imaginary app called KFoo in a git.kde.org code repository called 'kfoo'.
+More detailed information can be found on the main [[Development/Git|KDE Git page]], in particular the [[Development/Git#Git_for_SVN_Users|Git for Subversion Users]] section.  More details on the various commands can be found on the [[Development/Git/Recipes|KDE Git Recipes]] page.
-−
 More detailed information can be found on the main [[Development/Git|KDE Git page]].
 == Set-up ==

@@ Line 195: / Line 195: @@
 Make a note of the sha5 of the commit as you will need it later to copy the commit to the unstable master branch.
-Now you can merge your changes into the central code repository:
+Now you can push your changes into the central code repository:
   git pull --rebase
-  git push origin KDE/4.6:KDE/4.6    //TODO or use git merge???
+  git push origin KDE/4.6:KDE/4.6
 The next step is to apply the bug fix to the unstable master branch.  First check the master branch back out and update it:
@@ Line 214: / Line 214: @@
   git pull --rebase
-  git push origin master:master    //TODO or use git merge???
+  git push origin master:master

@@ Line 44: / Line 44: @@
 This section documents the basic workflow for developing a new feature for the master unstable branch (aka trunk in subversion).  You will first make local code changes and commit them in your local repository before pushing them to the central code repository.
-=== Making Local Change Commits ===
+=== Making Local Changes and Commits ===
 Changing and building code itself is no different from when using subversion, but how changed files are managed and committed is very different, as are the names and commands used.  There are two key differences:
 * Locally modified files can have different states that determine whether they get committed or not.
-* Committing code is only local, it does not merge your changes into the central repository which requires an extra step.
+* Committing code is only local, it does not push your changes to the central repository which requires an extra step.
 Files in a git repository can be in various states:
@@ Line 73: / Line 73: @@
    #   (use "git reset HEAD <file>..." to unstage)
+   #
-   #       modified:   kstagedfile.h
+   #       modified:   src/kstagedfile.h
+   #
    # Changed but not updated:
@@ Line 79: / Line 79: @@
    #   (use "git checkout -- <file>..." to discard changes in working directory)
+   #
-   #       modified:   kchangedfile.h
+   #       modified:   src/kchangedfile.h
+   #
    # Untracked files:
    #   (use "git add <file>..." to include in what will be committed)
+   #
-   #       kuntrackedfile.txt
+   #       src/kuntrackedfile.txt
 To add a changed file to the staging area, or to add a new file to be tracked by the repository:
@@ Line 102: / Line 102: @@
    git checkout <filename>
-The git commit command differs from the svn commit command in only creating a commit in your local clone of the repository, it does not merge the changes into the central repository.  This allows you to queue up a series of small changes before merging them into the central repository.  This local commit history can also be modified before you finally do merge the changes.
+The git commit command differs from the svn commit command in only creating a commit in your local clone of the repository, it does not merge the changes into the central repository.  This allows you to queue up a series of small changes before merging them into the central repository.  This local commit history can [[Development/Git/Recipes#Interactive_Rebasing|also be modified]] before you finally do push the changes.
 The git commit command adds all files in the staged state into a new commit:
@@ Line 136: / Line 136: @@
   git show <sha5>
-The Git diff, log and show commands have many options for changing what is shown.  In particular diff can show the difference between any two commits.
+The Git diff, log and show commands have many options for changing what is shown.  In particular diff can show the difference in a file between any two commits.
 === Pushing Your Changes To The Central Repository ===
-When you are ready to merge all your local commits into the central repository, you first need to update to the latest version of the master code in the central repository:
+When you are ready to push all your local commits to the central repository, you first need to update to the latest version of the master code in the central repository:
    git pull --rebase