Managing software development projects with Git

Git It Right

© Lead Image © Stephen Rees,

© Lead Image © Stephen Rees,

Article from Issue 216/2018

The Git version control system is a powerful tool for managing large and small software development projects. We'll show you how to get started.

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.

The Birth of Git

The Git version control system was born in an unexpected whirlwind of development back in the Spring and Summer of 2005. At the time, the Linux kernel developers were using the BitKeeper version control system. Unlike many version control tools of the time, BitKeeper had a distributed architecture, which worked well for the remote development process practiced within the dispersed kernel community.

The ever-practical Linus adopted BitKeeper because he saw it as the best available solution for the Linux team, however, BitKeeper came with some complications. The biggest issue was that, although BitKeeper was provided free of charge to the kernel team in what was called a "community" edition, it didn't have a free (as in freedom) open source license. Several restrictions were placed on using the software, including a prohibition against reverse engineering and creating unauthorized extensions. Several leading free software developers, such as Richard Stallman and Alan Cox, objected to a high-profile open source product like Linux using a non-free code management system, but the kernel community continued to use BitKeeper in an uneasy truce.

Then in 2005, word got out that Andrew Tridgell, creator of Samba, who was, at the time, an employee of the Open Source Development Labs (OSDL), then the overseer of Linux kernel development, had reverse-engineered the proprietary BitKeeper protocols and developed a free client, thus violating the BitKeeper license. BitMover, the company that owned and maintained BitKeeper, acted swiftly to cancel the community license, thus suddenly ending the kernel team's access to BitKeeper version control.

Linus already knew he didn't like any of the other code management systems available at the time, so when he lost access to BitKeeper, he started to build his own. The Git project was officially announced on April 6, 2005, and by June 16, it was already operational enough to manage the Linux kernel 2.6.12 release [2]. Linus passed the Git maintainership to Junio Hamano in July 2005, and Hamano has continued to develop and improve Git ever since. In an interview with TechCrunch in 2012, Linus said that one of his biggest successes was "…recognizing how good a developer Junio Hamano was on Git, and trusting him enough to just ask if he would be willing to maintain the project." [3]

Git has seen many improvements since 2005, thanks to Hamano and others within the Git development community, but the rapid rise of Git from the ashes of the BitKeeper debacle, and its gradual emergence as the world's most popular version control framework, have added another chapter to the legend of Linus Torvalds as a genius software developer. Linus isn't just the creator of Linux; he is creator of both Linux and Git – two incredibly successful tools that are in use all over the world.

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, the process is shown in Listing 1.

Listing 1

Name and Address

$ git config --global "John Doe"
$ git config --global
$ git config --list Doe

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").

A Question of Settings

Git saves the settings as a function of the option specified in the config command. You have three options: --system, --global, and --local. The setting determines the storage location for the configuration. The configuration files are evaluated in the opposite direction, starting with the local, project-specific data.

The documentation shows the specification of global, i.e., user-specific configuration data. The software stores the information tagged as --global in the .gitconfig file in the user's home directory. See the man page man git-config or the help with git help config for more information on configuration options.

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.

Listing 2

Creating a Project

$ 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.

Listing 3

Creating a 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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Git Ready

    If you develop open source software, you need to know how to use Git. Information on Git fills books, but this basic overview will get you started with a vital open source development tool.

  • Workspace: Subversion

    Even if you are not a programmer, you’ve probably heard of Subversion, a powerful tool for managing changes to software projects. Although Subversion is designed primarily for software developers, it can be useful to mere mortals as well.

  • Tree View

    Complex Git projects sometimes require a better view of the dependencies and branches. Several tools offer GUI options for Git. We take a look at gitk, gitg, git-gui, and GitAhead.

  • Branch Management

    Git makes version control as simple as possible. To manage your Git branches successfully, you need to learn the ins and outs of git branch and git merge.

  • Remote Git Repositories

    Software projects often comprise several code branches, some of which exist in parallel. Git supports community code development through remote repositories and code branching.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More