Using Git

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

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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 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 clone ssh://

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
* 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
$ 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 @@
-# (C) 2008 Red Hat, Inc.
+# (C) 2011 Red Hat, Inc.
 # All rights reserved.

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.