Using Git

From Dogtag
Revision as of 19:56, 16 January 2012 by Nkinder (talk | contribs)

Jump to: navigation, search

This page shows how to accomplish some common development procedures using Git. There are usually multiple ways to accomplish the same thing in Git, so keep in mind that the steps below are only one way of doing things. There may be other shortcuts or different ways of doing things that you prefer.

Creating a local repository

Our git repository is located on fedorahosted.org here. You can use one of the following commands to clone our Git repository (use the "ssh://" version of the clone command if you are authenticating with a Fedora account, otherwise use the anonymous "git://" version):

git clone git://git.fedorahosted.org/git/pki.git
git clone ssh://git.fedorahosted.org/git/pki.git

Developing on a local branch

The preferred way of doing development is to do your work on a local branch. This makes it easy to isolate fixes you are working on from each other. It also helps to prevent merge issues when you are ready to push your changes up to the remote repository. The following example shows the commands a developer would use to fix a bug on a local branch.

The first step is to create a local branch. You should name your branch something descriptive, such as the bug number you are working on, or the name of the feature you are developing. Here is an example of creating a new local branch:

$ git checkout -b my_branch
Switched to a new branch 'my_branch'

This command creates a local branch named my_branch and switches to it. If you ever want to check and see what branch you are on, you can do that with the following command:

$ git branch
  master
* my_branch

This shows that we have two local branches. The master branch is the branch created when we initially cloned the remote repository. This branch is set to track the development tip. The * next to my_branch means that we are currently on my_branch. If you ever want to switch the branch that you are on, that is done with the checkout command. Here is an example that shows switching to the master branch, then back to my_branch:

$ git checkout master
Switched to branch 'master'
$ git branch
* master
  my_branch
$ git checkout my_branch
Switched to branch 'my_branch'

Now that we are on our branch, we would change the source code to fix our bug. This example just makes a simple change to the copyright block in pki/README. After updating the source, we can see the changes with the diff command:

$ git diff
diff --git a/pki/README b/pki/README
index 2c2c36b..f6b2e83 100644
--- a/pki/README
+++ b/pki/README
@@ -1,5 +1,5 @@
 # BEGIN COPYRIGHT BLOCK
-# (C) 2008 Red Hat, Inc.
+# (C) 2011 Red Hat, Inc.
 # All rights reserved.
 # END COPYRIGHT BLOCK

We can see the status of the files in the source tree according to Git with the status command:

$ git status
# On branch my_branch
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	modified:   pki/README
#
no changes added to commit (use "git add" and/or "git commit -a")

This shows us that the only modified file in the source tree is pki/README. Note also that is says that the change to this file is not staged for commit. If you want to stage a file for commit, you can use the add command. Here is an example of staging the pki/README file for commit and then showing the status of it:

$ git add pki/README
[nkinder@localhost pki]$ git status
# On branch my_branch
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   pki/README
#

Now we can see that our modifications to pki/README are staged for commit. We will use the commit command at this point to check our changes in on our local branch.

$ git commit
[my_branch 535cf2d] Updated copyright in README file
 1 files changed, 1 insertions(+), 1 deletions(-)

When you run the commit command, you will have to fill in the commit message for your commit. The format should be a one-line summary of the fix (including the applicable bug or ticket number if appropriate), followed by a blank line and a more complete description of the change. Now that our change is commited to our local branch, we can look at the commit history to confirm that our commit is there. We'll also check the status of the tree to show that git considers the tree to be up to date.

$ git log -1
commit 535cf2d38b876ac784bd3449dea885b9da4b1c3c
Author: Nathan Kinder <nkinder@redhat.com>
Date:   Mon Jan 16 11:50:52 2012 -0800 

    Updated copyright in README file
   
    The date in the copyright of README needed to be updated.
$ git status
# On branch my_branch
nothing to commit (working directory clean)

The log command used above shows the last commit. If you want to see more history, you can simply change the -1 argument to the last number of commits that you want to see.