In the previous article we defined why Git offers a better solution for VCS than SVN; Git is faster, more reliable and flexible than SVN. But now that we know that, let’s take a look at Git and some if its capabilities.

The Basics of Git

Clone

In Git you don’t checkout a repo, you clone it. You end with a complete copy including the history of that repo in your local filesystem.

All the metadata information of a git repo is stored on the top level of that directory under the .git directory. Personally I found this a cleaner and less error prone than having one .svn under each single directory on your project.

#
$ git clone git://repository/address
#

Or if you want to checkout that repo to a specific directory just run:

#
$ git clone git://repository/address /my/destination/directory/
#

Here is another example of cloning my private repository for allanmacgregor.com website:

$ git clone git@github.com:macgregor/Website-Repo.git www.allanmacgregor.com
Cloning into Website-Repo...
remote: Counting objects: 1962, done.
remote: Compressing objects: 100% (1809/1809), done.
remote: Total 1962 (delta 119), reused 1962 (delta 119)
Receiving objects: 100% (1962/1962), 29.42 MiB | 1.72 MiB/s, done.
Resolving deltas: 100% (119/119), done.

Status

Just like in SVN, running the status command will show the state of our current repository, what files have been modified, added, removed etc. Let’s modify the README file inside our repo:

$ git status
# On branch master
# Changes not staged for commit:
#
#	modified:   README
#
no changes added to commit (use "git add" and/or "git commit -a")

Now let’s add the changes to the commit.

$ git status
# On branch master
# Changes to be committed:
#
#	modified:   README
#

And now after running the commit command and running status again we get:

# On branch master
nothing to commit (working directory clean)

Log

git log is probably the most underused of all git tools, compared with mercurial, svn or bazaar the git log tool is incredibly powerful. All that power doesn’t mean that using the log is complicated all the contrary; just run log inside your local repo and see the result:

$ git log
commit fa457df45526784c82ffcc17180991fa9ff1d2da
Author: Allan MacGregor 
Date:   Fri Jul 22 20:51:38 2011 -0230

    README Updated

commit f6177f98bbbd24ec0facce0aa428dd1d9e82360c
Author: Allan MacGregor 
Date:   Wed Jun 22 19:24:54 2011 -0230

    Initial Commit

Now that was the most basic and common usage of the git log command but let’s try something more advance lets get the log of all the patches applied to the repo:

 git log -p
commit fa457df45526784c82ffcc17180991fa9ff1d2da
Author: Allan MacGregor 
Date:   Fri Jul 22 20:51:38 2011 -0230

    README Updated

diff --git a/README b/README
index e69de29..a962041 100644
--- a/README
+++ b/README
@@ -0,0 +1,3 @@
+h1. Allan MacGregor Website Code
+
+Wordpress based website and blog with custom theme.

commit f6177f98bbbd24ec0facce0aa428dd1d9e82360c
Author: Allan MacGregor 
Date:   Wed Jun 22 19:24:54 2011 -0230

    Initial Commit

diff --git a/.htaccess b/.htaccess
:
commit fa457df45526784c82ffcc17180991fa9ff1d2da
Author: Allan MacGregor 
Date:   Fri Jul 22 20:51:38 2011 -0230

    README Updated

diff --git a/README b/README
index e69de29..a962041 100644
--- a/README
+++ b/README
@@ -0,0 +1,3 @@
+h1. Allan MacGregor Website Code
+
+Wordpress based website and blog with custom theme.
........

So you see with git log -p allows us to view all the patches with each commit entry; very useful if you want to do code reviews or see what other developers did.

But at this point you are probably wondering why the format has to look so bad, well that’s the thing it doesn’t; you only need to run git log –pretty=oneline

git log --pretty=oneline
fa457df45526784c82ffcc17180991fa9ff1d2da README Updated
f6177f98bbbd24ec0facce0aa428dd1d9e82360c Initial Commit

That’s very useful if you want to quickly overview all the changes in a repository and in a readable way; but what if we want a little more information in each commit then we can simply do:

$ git log --pretty=format:"The author of %h was %an, %ar%n>>%s<<%n"
The author of fa457df was Allan MacGregor, 33 minutes ago
>>README Updated<<

The author of f6177f9 was Allan MacGregor, 4 weeks ago
>>Initial Commit<<

Those are only a few examples of the many usages of the log command for more details on its usage take a look at the git log docs

Remote

Unlike CVCS like SVN where the server and the client are very different. Git repositories are basically equals and you basically synchronize between them. Well this is one of the Git superpowers multiple remote repositories.

Remote repos are very useful specially since you can have different permissions on each repo, that gives you a lot of flexibility for setting different workflows with your team. Let's take a look at the basics of remote repos.

$ git remote -v
origin	git@github.com:amacgregor/git-reference.git (fetch)
origin	git@github.com:amacgregor/git-reference.git (push)

You see the URL there twice because Git allows you to have different push and fetch URLs for each remote in case you want to use different protocols for reads and writes.

$ git remote add origin git://github.com/example2.git
$ git remote -v
github	git@github.com:amacgregor/example2.git (fetch)
github	git@github.com:amacgregor/example2.git (push)
origin	git@github.com:amacgregor/gitexample.git (fetch)
origin	git@github.com:amacgregor/gitexample.git (push)

Pull or Fetch + Merge

There are 2 ways to get the changes from a remote repo pull and fetch + merge. git fetch will synchronize you with another repo pulling down the data that you don't have locally and creating 'remote branches'; remote branches are identical to local branches and you can do almost everything that you can do with local branches(merge, diff, log, etc) except checking them out.

$ git fetch github
remote: Counting objects: 4006, done.
remote: Compressing objects: 100% (1322/1322), done.
remote: Total 2783 (delta 1526), reused 2587 (delta 1387)
Receiving objects: 100% (2783/2783), 1.23 MiB | 10 KiB/s, done.
Resolving deltas: 100% (1526/1526), completed with 387 local objects.
From github.com:schacon/hw
   8e29b09..c7c5a10  master     -> github/master
   0709fdc..d4ccf73  c-langs    -> github/c-langs
   6684f82..ae06d2b  java       -> github/java
 * [new branch]      ada        -> github/ada
 * [new branch]      lisp       -> github/lisp

The second command that we can use is git pull; basically this command will run git fetch and then immediately git merge.

Adding Files

In Git you have to add file contents to your local copy before you can actually commit them. Each time you make changes to your repo you need to run git add, the easiest and quickest way is to run the following command in your repo root directory:

#
$ git add .
#

That will add all unversioned files in the repo recursively, optionally you can run the command for just committing specific files:

#
$ git add README 
#

Oops... Reverting Changes

Ok, SVN users here is where it gets a bit confusing, pay attention. In Git if you want to undo some changes made since the last commit you use the git checkout command.

#
$ git checkout -- README
#

Basically it takes a new copy of the code from the HEAD of the repository and replaces the current version of that file.

Commit

So finally we get to learn how to actually commit or changes to our repository, you can simply run git commit and then git will ask your for a message to submit with the commit or you can simply do what I do:

#
$ git commit -m "Here is my commit Message"
#

Wasn't that easy? one single line and our commit is ready.

Push and Pull

Previously we learned that we that we can add remote repositories with the git remote command, but how do we synchronize with this remote repos. git push and git pull to the rescue.

Both commands work pretty much on the same way:

# Let's send our changes to the repo
$ git push remote_repo_name
# Let's get the changes from the repo
$ git pull remote_repo_name

This is just an start of the basics of using to managing your projects. Expect more articles with more detailed information about each one of the commands.

Related Posts:

• SVN vs Git #1: Why You Should Care