To be an effective software developer in any modern software development project, you must be able to develop concurrently with other project contributors. Source code management (SCM) systems are not a new idea. Many attempts have been made to write software that allows future software projects to be developed faster and easier. Most modern source code management solutions include revision control systems to allow retractions of source code changes that turn out to be detrimental to the project, or to simply track who changed what lines of code. Revision control systems attempt to address the problem posed by developers trying to alter a file simultaneously, preventing users from overwriting each others' alterations. Many of the currently popular solutions for source code management try to address failures in previous SCM solutions.
Centralized revision control systems typically work in one of two ways:
- Some provide file locking to prevent concurrent access. These systems lock files so that only one developer has write access to the central repository at a time.
- Others, such as CVS, allow multiple developers to edit the same file at the same time, and provide facilities to merge changes later.
Popular revision control systems include:
Quite simply, Git is Linus Torvalds' recently implemented source code management software. As the supplied documentation says, "Git is a fast, scalable, distributed revision control system with an unusually rich command set that provides both high-level operations and full access to internals."
Torvalds began working on Git as an interim solution to replace BitKeeper, which had previously been the primary source code tool in use by Linux kernel developers worldwide. Some members of the open source community felt that the BitKeeper license was not the best fit for the open source world, and thus Torvalds decided to investigate revision control systems with more permissive licenses. Though initially developed to aid in the Linux kernel development process, Git is finding new uses in other free software projects as well. For instance, X.org has recently switched to Git, as have many Freedesktop.org projects.
The current iteration of Git is intended primarily for use by software developers looking for alternatives to CVS or proprietary code management solutions. Git differs from CVS in a number of ways:
- Branching is fast and easy.
- Offline work is supported; local commits can be submitted later.
- Git commits are atomic and project-wide, not per-file as in CVS.
- Every working tree in Git contains a repository with a full project history.
- No Git repository is inherently more important than any other.
To install the current release of Git, you can use vendor-supplied packages that ship with your Linux distribution, or you can manually compile it from the latest stable snapshot. I recommend downloading a tarball containing the most recent stable snapshot of the Git source code; the release as of this writing is v1.4.0. You can find a link in the Resources section below.
Once you have this tarball, make sure that you have the proper dependencies for the initial installation. Your system must contain the following packages, along with their respective development headers:
- libcrypto (OpenSSL)
- rsync (version 2.6.0 or higher)
Once the dependencies are met, you can begin building your initial Git installation. The process should be familiar to most developers who have used Linux previously. Start off by untarring the package, using the appropriate unpacking method for your download:
$ tar -jxvf git-1.4.0.tar.bz2
$ tar -zxvf git-1.4.0.tar.gz
Then change to the appropriate directory and use the
make command. (Note that the directory name will depend on the date of the snapshot you've downloaded.)
$ cd git-1.4.0/ $ make prefix=/usr/local install $ sudo make prefix=/usr/local install
You will be prompted for the sudo password for installation to continue. Now you should be ready to begin using the Git tools.
When using Git to manage source code repositories, there are two main ways to get started. You can take a local directory of existing code and make a repository from it, or you can mirror a repository that someone else publishes.
For the purposes of this article, you'll obtain a mirror of Torvalds' published Git repository. The following command will create a Git repository directory called linux-2.6. This directory will contain a hidden dotfile directory called .git/.
$ git-clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \ linux-2.6
This step will take a long time, as Git is transferring the kernel source (which is hundreds of megabytes in size) from kernel.org to your local machine. The output will look rather unintelligible, and should scroll by relatively quickly if you have a fast Internet connection. Your output should resemble Figure 1.
Figure 1. Output produced when downloading the kernel source tree
Now change into the directory containing the newly downloaded kernel:
$ cd linux-2.6
At this point, you should have a working Linux 2.6 repository on your local machine! Now on to basic operations with this repository.
Normally when using Git, you can assume that your repository is a little bit behind what is located on kernel.org. So you would typically begin by updating your repository to the latest upstream kernel tree. This process is sometimes referred to as a fast-forward merge. Strictly speaking, you don't need to perform this now, as you just installed your repository and it should not be out of date. But it doesn't hurt to check just in case:
$ cd linux-2.6 $ git-pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git ...
If successful, you should see output that looks similar to the following:
receiving file list ... done sent 130 bytes received 21677 bytes 14538.00 bytes/sec total size is 127865858 speedup is 5863.52 Already up-to-date. $>
If your repository was not up to date, you would see some content transferred to your local machine over the network.
You'll need to check out files from the Git repository (the stuff in the hidden files) into the working directory to begin your hacking. The following command will place unhidden directories with the Linux source code in the current directory:
If you ever want to overwrite any of your local modifications, you can do another checkout with the
-f option to bring you back to a clean slate:
$ git-checkout -f
At this point, you should see the familiar Linux source code directory structure in your current working directory, and you can begin making modifications to the source.
You can now modify any file you choose. As a simple example, you'll modify something in the docs directory: you'll add a message that will be easily recognizable later. To make my example easier to follow, I chose not to modify code, but you are welcome to dive in and rewrite the entire kernel subsystem if you are so inclined.
First, let's open a file in an editor:
$ vi ./Documentation/ManagementStyle
Obviously, I'm using vi here, but you are, of course, free to use whatever editor you prefer to get the job done. In editing the file, I added a line before the first paragraph, as follows: "Eli shall be in charge of managing sandwich consumption. See Documentation/Sandwiches for more."
If you are satisfied with the alterations you have made and you feel you are ready to make them a permanent part of your repository, you simply need to check in your changes using the following command:
$ git-commit Documentation/ManagementStyle
You will be prompted to supply a commit message, which is a user-generated comment that will help other developers (or you, later) understand what exactly the change you just implemented did. In my case, the commit message was a sentence describing the alteration I had just made to the documentation.
If you would like to check the status of your work so far, you can execute
git-log to view the history of your local repository (which inherits the information of the repository that you cloned). Your commit message should be at the top of the log.
But wait! We never added a Documentation/Sandwiches file, so you need to add it to the working directory and tell Git about it when you're done. I created the file I wanted to add using the
echo command, since this is a simple example. Again, you can use whatever means you prefer.
$ echo "Turkey is superior" > Documentation/Sandwiches
Now that you've added a file, you need to make Git aware of this change by adding it to Git and then committing the revision. You can perform these tasks by executing the following commands:
$ git-add Documentation/Sandwiches $ git-commit Documentation/Sandwiches
If you had added multiple files, you could continue listing them after the
git-add command on a single line, as you need not add them one at a time. If you have to remove a file, there is no special command like
git-add; you just remove the file, then commit.
Now is a good time to check in on your
git-log to ensure that what you have done so far has been correct. This time, you will use the
-p option to see the log in individual patch format.
Finally, you will want to generate a text file containing only the differences between your modified source and the original. This file is typically created with the
diff utility, and is called a diff. The diff helps you create a patch file, which is the preferred way of sending code submissions to many open source projects. For more about diffs, see the links to Kernel.org in Resources below.
You can use Git to manage local repositories without mirroring someone else's work. For instance, if you would like to use Git to manage your own personal contributions to an open source project, you can begin by making a Git repository from a project snapshot.
Assuming you have a standard release tarball named release.tar.gz, you can create a local Git repository by issuing the following commands:
$ tar -zxvf release.tar.gz $ cd release $ git init-db
You may see messages stating saying that Git is "defaulting to local storage area." These messages are normal and indicate that you have a Git repository in place.
You've now initialized the working directory, and you should see a new directory, .git, within the project directory. To inform Git that you want to track each of the files in the project directory, issue the following command:
$ git add .
Finally, commit the monitored files to the repository with the following command:
$ git commit -a
Once again, you will be prompted for a commit message. From this point, you can work within your Git repository using all the functionality provided by Git, such as branching for experimental features, bisecting to track down regressions, and the doing the usual revision history functions.
For more information on managing branches and other interesting features of Git, check out the excellent Git tutorial at Kernel.org (see Resources for a link).
Now that you know how to use Git to obtain both the Linux kernel source and other Git-managed projects, you might choose to use Git to manage your next development project. Git is still relatively new and is under development. Additional scripts and tools are being implemented to make it even easier to use; see the examples in Resources.
Kernel.org has a number of good resources to get you started:
Kernel Hackers' Guide to git is a cookbook of recipes for getting up and running.
Learn more about revision control systems:
- "CVS for the developer or amateur" (developerWorks, March 2001)
- "Introducing Subversion: Version control for the third millennium" (developerWorks, June 2006)
- "StatCVS offers a view into CVS repository activity" (developerWorks, February 2005)
Linux for IBM System z9 and IBM zSeries
is an IBM Redbook about Linux on big iron.
In the developerWorks Linux zone, find more resources for Linux developers.
Stay current with developerWorks technical events and Webcasts.
Get products and technologies
Download Git source code.
QGit is a QT-based Git GUI.
Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.
Eli M. Dow is a software engineer in the IBM Test and Integration Center for Linux in Poughkeepsie, NY. He holds a B.S. degree in computer science and psychology and a master's of computer science from Clarkson University. He is an alumnus of the Clarkson Open Source Institute. His interests include the GNOME desktop, human-computer interaction, virtualization, and Linux systems programming. He is the coauthor of an IBM Redbook Linux for IBM System z9 and IBM zSeries.