Collaboration

Learn to use Git version control for added flexibility

Vincent Danen introduces Git, a distributed version control system that gains extra flexibility from being free of a central server, like Subversion or CVS. Here are some of the features that set it apart.

Git is a distributed VCS (Version Control System) that is quickly gaining popularity among many companies and projects. Take a look at the GitHub site, and you'll see a number of projects reside there.

Many projects have converted from "traditional" version control systems like CVS and Subversion to Git because of the flexibility and features it provides.

One main feature is that it is distributed, which means that there is no central server. Unlike Subversion, you can commit to a Git repository whether you are online or not. With Subversion, if you were doing programming on a plane, you'd have to wait until you could reach the central repository in order to commit your changes to the repository. With Git, you have your own repository that is cloned from the master repository, which means you can commit to it as often as you like, whether you have Internet connectivity or not. When you do have connectivity again, you don't commit your changes back to the master repository, you merge your changes in.

If you are used to something like Subversion already, Git may seem a little strange at first but you will quickly get the hang of it.

To start with, let's clone a project from GitHub. In this case, we'll clone the Rails Git repository:

$ git config —global user.name "The Wizard of Oz"
$ git config —global user.email "wizard@oz.com"
$ git clone git://github.com/rails/rails.git
Initialized empty Git repository in /home/wizard/git/rails/.git/

Here we are doing a few things. We are first setting our username and email address. Next, we are cloning the rails.git repository, which will be stored locally in the ./rails/ directory. This is the source tree, and repository.

Now you can do regular development tasks in the directory. If you want to see what changes have been made, use git log to view the commit log. If you want the log of a particular file, use git log [file] to see commit messages specific to that file.

If you make changes to a file and want to see a diff of those changes from those in the repository, use git diff. The output is similar to an svn diff or cvs diff -uN command. To add a file, use git add:

$ echo "test file" >test.txt
$ git add test.txt
$ git commit -m "test file"
[master 1e5d1bb] test file
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 test.txt
$ echo "add another line" >>test.txt
$ git diff test.txt
diff —git a/test.txt b/test.txt
index 16b14f5..3d87308 100644
—- a/test.txt
+++ b/test.txt
@@ -1 +1,2 @@
test file
+add another line

At this point we have added a new file to our cloned repository, committed it, changed it, and generated a diff of the changes. During all of this, we have made no changes to the master repository; we have only been changing our cloned copy. If this were done in a plane, in the back of a car, or in a log cabin deep in the woods, we would be okay: all of the changes made are to our local repository and you can branch, back out, diff, and otherwise manipulate the repository — all things that would require an Internet connection with Subversion or other version control systems.

If the changes made to this repository had been relevant, we would merge them back using the "git push" command. This can be used on a specific file or with the "-a" (or "all changes") switch.

Or you could never merge your changes back to the master. You could easily clone a repository for personal use or learning purposes, to fork a project, whatever. With Git, when you clone a repository, you are making your own personal copy with full history, meaning you can manipulate it at will. And you don't have to merge back the whole thing — you can merge back specific commits or files.

Git has more of a learning curve than Subversion, but it also provides some really neat and useful features that make it highly appealing, and worth taking the time to look into. And for folks wanting to use Git but forced into using Subversion, or Subversion users who need to be able to work offline, git-svn provides a bidirectional bridge between a Subversion repository and a local Git repository.

Get the PDF version of this tip here.

Delivered each Tuesday, TechRepublic's free Linux and Open Source newsletter provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!

About Vincent Danen

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

Editor's Picks

Free Newsletters, In your Inbox