Introduction

Welcome to Git: Distributed Version Control – Fundamentals and Workflows.

In this introduction, you will find what Git can do for you and why you need this book.

Why Git?

Git has a tremendous success story behind it. In April 2005, Linus Torvalds began to implement Git because he did not like any of the open-source version control systems available at that time.

Today, searching for “git version control” on Google returns millions of results. Git has almost become a standard for new open-source projects. Many large open source projects have already been migrated to Git or are about to be.

Here are some of the reasons why so many people are choosing Git.

• Git allows you to work with branches: In a project where many developers work in parallel, there will be many different lines of development. The strength of Git lies in the tools that can help development strands re-integrate: merging, rebasing, cherry-picking, etc.
• Flexibility in the workflow: Git is exceptionally flexible. A single developer can use it, an agile team will find ways to work with it and even a large international project with numerous developers at multiple sites can develop a good workflow with it.

• Contribution: Most open source projects exist through voluntary contributions from developers. It is important to make the process of contributing as simple as possible. With a centralized version control system, this is often difficult because you do not want to give everyone write access to the repository. With Git, anyone can clone a repository, work independently and later pass the changes around.
• Performance: Git is still fast even when handling a project with many files and a long history. For example, Git can switch the current version of Linux kernel sources to a six-year older version in less than a minute on a Macbook Air. This is impressive considering there are over 200,000 commits and 40,000 changed files between the two versions.
• Robust against failures and attacks: Since the project history is spread over a number of distributed repositories, a serious loss of data is unlikely. An ingeniously simple data structure in the repository ensures that data will still be interpreted correctly in the distant future. The consistent use of cryptographic checksums makes it difficult for attackers to tamper with a repository unnoticed.
• Offline and multi-site development: The distributed architecture makes it easy to develop offline or when traveling. In multi-site development, neither a central server nor a permanent network connection is required.
• Strong open source community: In addition to detailed official documentation, there are numerous manuals, forums, wikis, etc. There is an ecosystem of tools, hosting platforms, publications, services and plug-ins for development environments, and it is growing healthily.
• Expandability: Git offers convenient commands for the user, including commands that allow for more direct access to the repository. This makes Git very flexible and allows individual applications to have more than what the default version of Git offers.

A Book for Professional Developers

If you are a developer working in a team and wanting to know how to use Git effectively, then you are holding the right book. This book is not a theory-heavy tome or a comprehensive reference. It does not explain all the commands in Git (there are more than 100) or all the options (some commands have over 50 options). Instead, this book teaches you how to use Git in typical project environments, such as how to set up a Git project and how to create a Git release.

About This Book

Here is what you can expect from this book.

• Getting Started: Shows an example of every important Git command in less than a dozen pages.
• Introduction: In not more than a hundred pages you will learn everything you need to work with Git in a team. A large number of examples show how to use the main Git commands. Furthermore, basic concepts, such as commit, repository, branch, merge and rebase, are explained to help you understand how Git works. You will also find a section containing tips and tricks that you probably do not need every day, but which sometimes can be useful.
• Workflows: Workflows describe scenarios where you can use Git in a project, such as when you want to create a release. For each workflow the following is explained so that the desired results can be achieved:
• ▪ what problem it solves,
• ▪ what conditions must be added, and
• ▪ who has to do what and when it has to be done.
• “Why This Solution?” sections: Each workflow describes exactly one concrete solution. In Git, there are often very different paths that you can take to achieve the same goal. In the last part of each workflow chapter we explain why we have chosen exactly this solution. We will mention if there are variations and alternatives that might be of interest to you.
• “Step by Step” instructions: Frequently used command sequences, such as moving a branch, are given in “Step by Step” instructions.

Why Workflows?

Git is extremely flexible. It can be used by many in different roles, from a single system admin who needs to version a few shell scripts occasionally, to the hundreds of developers in the Linux kernel project. Anything is possible. However, this flexibility comes at a price. Before you start working with Git, you have to make a number of decisions. For example:

• In Git you have distributed repositories. However, will you really only work locally? Or will you prefer to set up a central repository?
• Git supports two types of data transfer: push and pull. Should you use both? If you choose one, which one? Why not the other?
• Branching and merging are two of the features Git is strong in. But how many branches should you open? One for each software feature? One for each release? Or just one?

To get you started, we have summarized what workflows are or do:

• Workflows are procedures for everyday project work.
• Workflows give specific instructions.
• Workflows show the necessary commands and options.
• Workflows are well suited for teams who are working closely, as those in modern software projects often are.
• Some workflows are not the only right solution for the problem, but are a good starting point from which you can develop efficient workflows for your project.

We focus on agile development teams working on commercial projects, because we believe that many professional developers (including the authors) are working in such environments. Not included are special requirements that are suited for large projects because they have significantly inflated workflows and because we believe that they are not that interesting to most developers. Also not included is the open source development, although there is a very interesting workflow with Git for this.

Tips for the Reader

As authors we obviously want you to read our book from cover to cover. But, let's face it: Do you have time to even read more than a few pages? We suspect your project is still ongoing and that working with Git is only one of a hundred issues that you are dealing with at this moment. Therefore, we have made every effort to write a book that people can skim over. Here are a few things to consider:

Do I have to read the introductory chapters to understand the workflows?

If you have no previous knowledge of Git, then yes. You need to master the basic commands and principles to be able to use the workflows correctly.

I have worked with Git. Which chapters can I skip?

There is a summary on the last page of every introductory chapter (Chapters 1 to 11). Here you can read very quickly to figure out if there are still things new to you in the chapter or if you can skip the whole chapter. The following are chapters you can safely skip because they are only relevant for some workflows:

• Chapter 5, “The Repository”
• Chapter 8, “A Cleaner History with Rebasing”
• Chapter 10, “Version Tagging”
• Chapter 11, “Dependencies between Repositories”

Where Can I Find It?

• Step by Step instructions.
• Commands and options: If you want to know, for example, what a command does and what options can be used with it, see the Index. Almost all commands and options are listed there.
• Technical terms: Naturally, all terms in this book can be found in the Index.

Examples and Notations

We use the command line in many examples in this book. This does not mean there is no graphical user interfaces for Git. In fact, there are already two graphical user interface (GUI) applications for Git. In addition, there are numerous Git front-ends, including the following.

• Atlassian SourceTree (http://www.sourcetreeapp.com)
• TortoiseGit (http://code.google.com/p/tortoisegit)
• SmartGit (http://www.syntevo.com/smartgit)
• GitX (http://gitx.frim.nl)
• Git Extensions (http://code.google.com/p/gitextensions)
• tig (http://jonas.nitro.dk/tig)
• qgit (http://sourceforge.net/projects/qgit )
• Git in development environments that support Git internally, such as IntelliJ8 (http://www.jetbrains.com/idea) and Xcode 4 (http://developer.apple.com/technologies/tools)
• Git plug-ins for integrated development environments, such as Egit for Eclipse (http://eclipse.org/egit), NBGit for NetBeans (http://nbgit.org), Git Extensions for Visual STUDIO (http://code.google.com/p/gitextensions)

In spite of this, we have decided to use the command line in the examples because

• Git command line commands work on all platforms,
• the examples will work with future versions of Git,
• they thus represent very compact workflows,
• we believe that working with the command line is most efficient for many applications.

In the examples we use the standard bash shell on Linux and Mac OS systems. On Windows you can use the “Git Bash” shell (included in msysgit, a Git application for Windows that can be downloaded from http://msysgit.github.io) or cygwin.

A command line call looks like this.

> git commit

Where interesting, we also show the response from Git, e.g.

> git --version

git version 1.8.3.4

Acknowledgments

Looking back, we are amazed at how many people have contributed to the creation of this book in one or the other way. We would like to thank all those without whom this book would not have been what it is now.

First of all we would like to thank Anke, Jan, Elke and Annika, who now barely remember what we look like without a laptop under our fingers.

We would also like to thank the friendly team at dpunkt Publishing, the publisher of the original (German) edition of this book, especially Vanessa Wittmer, Nadine Thiele and Ursula Zimpfer. Special thanks to René Schonfeldt, Maurice Kowalski, Jochen Schlosser, Oliver Zeigermann, Ralf Degner, Michael Schulze-Ruhfus, and half a dozen anonymous reviewers for their valuable feedback that helped make this book better.

Standing on the Shoulders of Giants

A special thanks to Linus Torvalds, Junio C. Hamano and the many committers of the Git project. They have given the developer community this fantastic tool.