If Linus Torvalds were not already famous for Linux, he would be almost as famous for Git [1]. Within a few years of its first release in 2005, Git had become the dominant version control system in free software, replacing CVS and eclipsing rivals like Mercurial. Part of Git's popularity is no doubt due to Torvalds' own reputation, but a large part is also its highly organized structure: Every copy of Git is a complete repository with history and version-tracking tools that operates without a network or centralized server, giving it unmatched flexibility.

Torvalds began Git after BitKeeper, the proprietary version control system that the Linux kernel project had begun using in 2002, withdrew permission to use it freely, claiming that Andrew Tridgell had reverse engineered another version control system from it  [2]. Because version control is a necessity for development, Git was functional within a few weeks. Torvalds jokes that "git" is English slang for an unpleasant person, and the command is therefore named for himself, just as Linux is [3]. More obviously, "git" is the pronunciation of "get" in some American dialects. The truth is, after a few months, Torvalds passed maintenance of the project over to Junio Hamano, and Git has continued to grow in complexity ever since.

Git's basic purpose is to create an environment for developing files – usually code, but sometimes text as well. Entire books have been written about Git, but here is an overview to get you oriented. For all the detail, the basics are actually simple and become more so with practice.

Setting Up a Repository

Git's use in the kernel guarantees that it is available in every major distribution. The easiest way to set up a local repository is to clone a repository online using the command:

git clone URL

This command uses the HTTPS protocol to create a directory with the same name as the last directory in the URL (Figure 1). You can use another protocol, including git, or specify a new name for the directory at the end of the command. This method has the advantage of reproducing a complex structure with a single command. In cases like Arduino firmware, this advantage is essential, because to flash your hardware generally requires a set structure for directories or files. To keep the local repository in sync with the original, type:

git pull URL

Figure 1: The clone subcommand is a quick way to set up and configure a Git repository.

Updated files will be downloaded and merged, and new files will be downloaded.

To start a new repository, create a directory and change to the directory. Typing

git init

creates a skeletal repository that is ready to receive files. If the directory already has files, they are drawn into the repository. You will also want to configure the new repository with:

git config --global user.name "NAME"
git config --global user.email "eMAIL"

Other configuration options are also available, including the setting of display colors and the default text editor [4]. When your local repository is set up, git status will give you a brief message: Initialized empty Git repository in DIRECTORY.

A third alternative is to use an online host like GitHub or GitLab and follow directions after creating an account. This is the most popular choice when you are working with others, especially if you do not have the hardware to host a project yourself or would prefer not to worry about your privacy and security.

Staging Files

A repository can have two types of files: tracked files, which have been added to Git, and untracked files, which have not. Untracked files may be works in progress that are not ready to be added to Git and may be edited freely. You can view the state of all files using git status, but Git's chief purpose is to manage tracked files. Tracked files go through a cyclical life cycle until they are removed as shown in Figure 2.

Figure 2: The cyclical life cycle of a tracked file.

Adding a file to Git is often called staging. Staging simply means that Git is aware of a file and ready to work with it. The basic structure is:

git add FILE1 FILE2

A more precise commit can be made by using options, such as --interactive (-i) or --patch (-p) [5]. If you use --interactive, you receive a table for fast selection of your next command (Figure 3).

Figure 3: add's --interactive option lets you choose your next command from a table.

In contrast to adding a file, removing one requires some caution. The command:

git rm FILE

will remove a file from your local hard drive, as well as from Git. Often, though, you may want to stop Git from being aware of the file, but not to delete it from your system, in which case the command you need is:

git rm --cached FILE

Making a Commit

Once a file is added, edited, or removed, you need to commit it. A commit is a snapshot of the repository, typically made each time after at least one file has been changed. The command git status lists all staged but uncommitted files (Figure 4). You can commit groups of files with the same command:

git commit -m "MESSAGE"

Figure 4: The status subcommand shows the complete state of the repository.

You will probably want to add to the command the option --author="AUTHOR" so that you take responsibility for your changes and receive credit for them as well. If you do not use the -m option, the editor in Git's environment opens so that you can write a detailed description (Figure 5). A repository's initial state is referred to as the HEAD, while a commit generally begins a new development branch of the code. For example, in the Linux kernel, each version number has its own branch.

Figure 5: Before a commit is entered, Git summarizes the repository's state and gives you the chance to describe the changes you have made.

A commit is needed each time a file is added, edited, or removed. As commits are made, they are listed when git status is run. Changes from one commit to another can be read using git diff to see what has been done to the complete repository; you can also use git diff FILE.