Development/Tutorials/Git/Basics: Difference between revisions

Revision as of 03:14, 2 November 2009

This tutorial will show you the basics for Git.

Setting up Git

For Git to work properly, it needs to store some personal information for use in email merge requests and in the commit logging.

git config --global user.name "Your Name" git config --global user.email [email protected]

Additionally, to allow colorized output in Git.

<coded> git config --global color.ui true

There are other additional color-related features which are discussed in the fine documentation that comes with Git.

In case you experience problems with colorized output you may test adding the following to your ~/.bashrc to verify.

R needed for git colours

export LESS="-RIM"

First steps with Git

Getting started with Git for KDE is fairly easy. First, run the following:

git clone <REPOSITORY URL>

This creates a local copy of the upstream repository. Now change into that directory and code away. When updating, run:

git pull

To check the status of the repository. use the status sub-command to view the state of the local copy:

$ git status

On branch master

Initial commit

Untracked files:
(use "git add <file>..." to include in what will be committed)

testfile

nothing added to commit but untracked files present (use "git add" to track)

If 'testfile' should be added to the local copy, run the add sub command:

$ git add testfile

Once 'testfile' has all the changes desired, commit it to the local copy:

$ git commit -m "This is the first commit" Created initial commit 246d7aa: This is the first commit

1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 testfile

Much like svn status, if you change a file once it has been committed, running git status will show that the file was modifed since last commit:

$ echo "new content" > testfile $ git status

On branch master
Changed but not updated:
(use "git add <file>..." to update what will be committed)

modified:   testfile

no changes added to commit (use "git add" and/or "git commit -a")

Branches and merging are cheap in Git

When creating changes to the code from the upstream repository that will later get merged back upstream, branches are highly recommended.

To view the current set of branches available, run git branch. The branch with a proceeding '*' is the active one. To create a new branch called "bugfix-branch" for example, run:

$ git branch bugfix-branch $ git checkout bugfix-branch Switched to branch "bugfix-branch"

Make the changes necessary changes to the branch and then get ready to merge them back to the master branch

$ git checkout master Switched to branch "master" $ ls testfile $ git merge bugfix-branch Updating 14a9802..3264357 Fast forward

newfile |    1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 newfile

$ ls newfile testfile

If there had been changes made to the branch, git would have automatically tried to merge the changes in the bugfix-branch with the master branch.

Rarely, this can cause a merge conflict. In those cases, manually edit the files that conflict in the master branch, and then do a git commit -a to complete the merge. Git indicates the conflicting lines within the file that cannot be auto-merged.

Viewing the Change log

To view the change log for a given file in the local copy, run git log <FILENAME>.

$ git log testfile commit 14a9802e249413003d1fa40002baa025aa54c75f Author: Carsten Niehaus <[email protected]> Date: Fri Apr 18 18:07:18 2008 +0200

   Second commit

commit 246d7aad05139314e7ff62a5becb6c930f72fb8f
Author: Carsten Niehaus <[email protected]>
Date:   Fri Apr 18 18:06:33 2008 +0200

   This is the first commit

@@ Line 3: / Line 3: @@
 == Setting up Git ==
-First, you should tell Git your name and email address. These information will be shown in the log and in commits. Also, you should allow color in Git. There are other color-related features, but this tutorial is just about basics.
+For Git to work properly, it needs to store some personal information for use in email merge requests and in the commit logging.
 <code>
 git config --global user.name "Your Name"
 git config --global user.email [email protected]
+</code>
+Additionally, to allow colorized output in Git.
+<coded>
 git config --global color.ui true
 </code>
-In case you experience problems with colors you should test adding the following to your ~/.bashrc. The 'R' is the important part here.
+There are other additional color-related features which are discussed in the fine documentation that comes with Git.
+In case you experience problems with colorized output you may test adding the following to your <tt>~/.bashrc</tt> to verify.
 <code>
@@ Line 20: / Line 27: @@
 == First steps with Git ==
-There are two ways to get started with Git for KDE. If you're only wanting to get code to try it out, you can use the following commands:
+Getting started with Git for KDE is fairly easy. First, run the following:
 <code>
@@ Line 26: / Line 33: @@
 </code>
-This creates a local copy of the upstream repository. Now change into that directory and code away. When you want to update:
+This creates a local copy of the upstream repository. Now change into that directory and code away. When updating, run:
 <code>
@@ Line 32: / Line 39: @@
 </code>
-Later, if you want to create a new Git repository and add files to it, try the preceeding commands:
+To check the status of the repository. use the <tt>status</tt> sub-command to view the state of the local copy:
-<code>
-$ git init
-Initialized empty Git repository in .git/
-$ echo "Test content" > testfile
-</code>
-Now we will check the status of the repository. Git will list one untracked file, that means the file has not yet been added to the repository.
 <code>
@@ Line 55: / Line 54: @@
 </code>
-In the next three commands the file 'testfile' will be added and commited. Then  Git will check the status again.
+If 'testfile' should be added to the local copy, run the <tt>add</tt> sub command:
 <code>
 $ git add testfile
+</code>
+Once 'testfile' has all the changes desired, <tt>commit</tt> it to the local copy:
+<code>
 $ git commit -m "This is the first commit"
 Created initial commit 246d7aa: This is the first commit
 files changed, 1 insertions(+), 0 deletions(-)
   create mode 100644 testfile
-$ git status
-# On branch master
-nothing to commit (working directory clean)
 </code>
-Ok, as you can see the file has been commited. Now let's see what we change the contents of the file:
+Much like <tt>svn status</tt>, if you change a file once it has been committed, running <tt>git status</tt> will show that the file was modifed since last commit:
 <code>
@@ Line 80: / Line 81: @@
 #
 no changes added to commit (use "git add" and/or "git commit -a")
-$ git commit -a -m "Second commit"
-Created commit 14a9802: Second commit
-files changed, 1 insertions(+), 1 deletions(-)
 </code>
-You see that Git noticed the changes in the file. <i>"git commit -a"</i> commits all changes in the repository. Note: This command does not add newly created files.
+== Branches and merging are cheap in Git ==
-== Branches and merging are cheap in Git ==
+When creating changes to the code from the upstream repository that will later get merged back upstream, branches are highly recommended.
-<i>git branch</i> shows you the branches of the repository, the one with the '*' is the active one. So let us create a new branch called <i>"bugfix-branch"</i> and assume we want to fix a branch there. After this fix (in this case the new file) we will merge back all the hard work into the master branch.
+To view the current set of branches available, run <tt>git branch</tt>. The branch with a proceeding '*' is the active one. To create a new branch called <tt>"bugfix-branch"</tt> for example, run:
 <code>
-$ git branch
-* master
 $ git branch bugfix-branch
 $ git checkout bugfix-branch
 Switched to branch "bugfix-branch"
-$ git branch
-* bugfix-branch
-  master
-$ echo "a second file" > newfile
-$ git commit -a
-# On branch bugfix-branch
-# Untracked files:
-#   (use "git add <file>..." to include in what will be committed)
-#
-#       newfile
-nothing added to commit but untracked files present (use "git add" to track)
-$ git add newfile
-$ git commit
-Created commit 3264357: This file is here for a demonstration of Gits branch- and merge feature
-files changed, 1 insertions(+), 0 deletions(-)
- create mode 100644 newfile
 </code>
-Ok, the bug is fixed now. Next step: Checkout the master branch and merge the two branches:
+Make the changes necessary changes to the branch and then get ready to merge them back to the master branch
 <code>
@@ Line 132: / Line 112: @@
 </code>
-If you would have edited "testfile" in the bugfix-branch, then git would automatically try to merge the contents of "testfile" in the bugfix-branch with the contents of "testfile" in the master branch. Sometimes this can cause a merge conflict. In that case you have to manually edit the "testfile" in the master branch, and afterwards you do a "git commit -a" to complete the merge. Git indicates the conflicting lines in the file itself.
+If there had been changes made to the branch, git would have automatically tried to merge the changes in the bugfix-branch with the master branch.
+Rarely, this can cause a merge conflict. In those cases, manually edit the files that conflict in the master branch, and then do a <tt>git commit -a</tt> to complete the merge. Git indicates the conflicting lines within the file that cannot be auto-merged.
+== Viewing the Change log ==
-== Lets now have a look at the log of the testfile ==
+To view the change log for a given file in the local copy, run <tt>git log <FILENAME></tt>.
 <code>
@@ Line 149: / Line 133: @@
      This is the first commit
-</code>
-== Handling local changes ==
-git-svn cannot sync with SVN when you have local, uncommited changes. For that you are using <i>git stash</i>. That command move the local changes on a stack so that you can sync. After the sync you re-apply them to you Git tree and clear the stack. Very handy feature in many situations! Just do this:
-<code>
-git stash
-git svn rebase
-git stash apply
-git stash clear
-</code>
-If you have local changes which you would like to revert use the following command. It will revert all local, uncommited changes.
-<code>
-git checkout -f
 </code>