Special Thanks: This article was made possible by support from Linux Professional Institute

With its egalitarian spirit and tradition of strong community involvement, open source development doesn't scale very well without some form of version control.

Over the past several years, Git [1] has settled in as the most viable and visible version control tool for the Linux space. Git was created by Linus Torvalds himself, and it got its start as the version control system for the Linux kernel development community (see the box entitled "The Birth of Git"). Since then, Git has been adopted by hundreds of open source projects and is the featured tool on several large code-hosting sites, such as GitHub.

Even if you aren't a professional developer, if you work in the Linux space, you occasionally need to download and compile source code, and, more often than not, that means interacting with Git. Many Linux users pick up occasional Git commands on the fly without ever getting a formal introduction to what Git is and how it works. This article is the first in a two-part series aimed at building a better understanding of Git for everyday Linux users. This first article shows how to install Git, create a Git project, commit changes, and clone the repository to a remote location. Next month, you'll learn some advance techniques for managing code in Git.

Git makes it easy to manage different versions of files side by side. The software is decentralized, and a server connection is only required for synchronization. Daily work is handled locally, which leads to much better performance. And after more than ten years of active development, Git is surprisingly easy to use, even for beginners.

Before You Start

Git is included with almost all distributions. On Red Hat systems, you can complete the install with sudo yum install git, and on Ubuntu, enter

sudo apt install git

You first need to configure a name and an email address. Without this information, Git either issues a warning or generates a dummy name and address. For the user John Doe with the email address john.doe@example.org, the process is shown in Listing 1.

$ git config --global user.name "John Doe"
$ git config --global user.email john.doe@example.org
$ git config --list
user.name=John Doe
user.email=john.doe@example.org

The git config --list command displays the settings. You can change these settings at any time. Git uses a multi-level structure for these settings (see the box entitled "A Question of Settings").

Let's Go

The project in this example is located in the ~/mproject directory and consists of the text files readme.txt and project.txt. The commands from Listing 2 create the project, but they do not yet create a repository.

$ cd
$ mkdir mproject
$ cd project
$ echo "readme.txt file" > readme.txt
$ echo "file project.txt" > project.txt

Creating the actual repository requires three steps (Listing 3): First, initialize the project in the main directory, in this case ~/mproject, then register the files it contains, and transfer them to the Git database, the repository.

$ cd ~/project
$ git init
Empty git repository initialized in /home/john/mproject/.git/
$ git add readme.txt
$ git add project.txt
$ git commit -m "First Commit"
[master (Basic-Commit) 77558e4] First Commit
 2 files changed, 2 insertions(+)
 create mode 100644 readme.txt
 create mode 100644 project.txt

The git init command creates an empty repository in the .git subdirectory (a hidden directory). It doesn't matter whether or not the files are in the actual directory, Git does not take project-specific data into account.

Use git add to add a file to the index. The current version of the file is now in the staging area. It contains versions that are flagged for the next commit. Or in Git speak: The file is staged.

The git commit command adds the marked files to the repository. This process is known as a commit or check-in. Each commit has its own text. Git displays the first line of the text in various outputs; it should therefore be short and as precise as possible. You can then describe the commit in detail, separated by an empty line.

You pass this text to the software with the -m option. Without this option, Git starts the default editor, unless configured otherwise (Figure 1). If no entry exists, Git aborts the commit.

Figure 1: A commit without specifying text brings up the default editor.

Properly Managed

A version control system (VCS) manages versions, or, more precisely, versions of files. A version is created when you add a file to a project or edit a file already contained in the project. Using this system, you define the version of a project, such as a program or a web page.

A VCS logs who made what changes, when, and why. The log makes it possible to trace the changes, compare different versions, and restore previous versions. It also displays the changes that project members have made in parallel.

The software manages the files in a repository, or repo for short, which is basically a directory [4]. Since the work is usually done on a copy, and the original is typically located in another directory (ideally on a different physical medium); a kind of backup is automatically created.

If several people work on a project, the use of a VCS is actually obligatory. Synchronization quickly becomes a problem without it.