English Sign in (or register) Technical topics Evaluation software Community Events Manage source code using Git Toolset provides reliable revision control on Linux Eli M. Dow (emdow@us.ibm.com), Software Engineer, IBM Summary: Git is the open source revision control software that Linus Torvalds developed to help manage Linux kernel development. You can download it yourself and use it for your own kernel hacking -- or for software development projects of your own. This article shows you how to get started hacking Linux with the Git tools. [Update: Two code listings have been modified to reflect the replacement of the rsync protocol with the newer git protocol for fetching source code -- Ed.] Date: 06 Jul 2006 (Published 29 Jun 2006) Level: Intermediate Also available in: Russian Japanese Activity: 59686 views Comments: 1 (View Add comment - Sign in) Rate this article Average rating (101 votes) Show articles and other content related to my search: eli m. dow 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: CVS Subversion Arch Bazaar BitKeeper What is Git? 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 1/8
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. Installation 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: zlib libcurl 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 or $ 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. Obtaining the latest kernel source tree 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 \ 2/8
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. Updating your local Git repository 3/8
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. Checking files out of the repository 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: $ git-checkout 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. Modifying existing files 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: 4/8
$ 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. Adding or removing files 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. $git-log -p Creating diffs 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. What else can Git do? 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 5/8
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). Conclusion 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. Resources Learn Kernel.org has a number of good resources to get you started: A tutorial introduction to Git Git for CVS users Everyday Git with 20 commands or so 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, 6/8
Tivoli, and WebSphere. With IBM trial software, available for download directly from developerworks, build your next development project on Linux. Discuss Check out developerworks blogs and get involved in the developerworks community. About the author 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. Close [x] developerworks: Sign in IBM ID: Need an IBM ID? Forgot your IBM ID? Password: Forgot your password? Change your password Keep me signed in. By clicking Submit, you agree to the developerworks terms of use. Submit Cancel The first time you sign into developerworks, a profile is created for you. Select information in your developerworks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post. All information submitted is secure. Close [x] Choose your display name The first time you sign in to developerworks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks. Please choose a display name between 3-31 characters. Your display name must be unique in the developerworks community and should not be your email address for privacy reasons. Display name: (Must be between 3 31 characters.) By clicking Submit, you agree to the developerworks terms of use. Submit Cancel 7/8
All information submitted is secure. Average rating (101 votes) 1 star 1 star 2 stars 2 stars 3 stars 3 stars 4 stars 4 stars 5 stars 5 stars Submit Add comment: Sign in or register to leave a comment. Note: HTML elements are not supported within comments. Notify me when a comment is added1000 characters left Post Total comments (1) make prefix=/usr/local install i think should be make prefix=/usr/local all Posted by denisboyun on 19 January 2012 Report abuse Print this page Share this page Follow developerworks About Feeds and apps Report abuse Faculty Help Newsletters Terms of use Students Contact us IBM privacy Business Partners Submit content IBM accessibility 8/8