Preface
Git was developed in early 2005 by Linus Torvalds, the creator and current maintainer of the Linux kernel. For the management of the kernel sources, the development team had initially decided to use the commercial version control system BitKeeper. Problems arose when the company behind BitKeeper, which provided the tool to the project free of charge, accused a developer of revealing the mechanisms of the software by reverse engineering. As a result, Torvalds decided to write a new version control system.
Simply switching to another system was not an option: The alternatives had a centralized architecture and did not scale well enough. The requirements of the kernel project on a version control system are, however, also huge: Between a little version jump (e.g. 2.6.35 to 2.6.36) there are over 500,000 changed lines in almost 1000 files. Responsible for this are over 1000 individuals.
So what were the Design Goals of the new program? Two characteristics crystallized quickly as design goals: speed or performance and verifiable integrity of the managed data.
After only a few weeks of work, a first version of Git was able to manage its own source code. Implemented as a small shell script collection with performance-critical parts in C, this version was still far from being a “full-fledged” version control system.
Since version 1.5 (February 2007), Git offers a new and tidier user interface and extensive documentation, allowing people not directly involved in Git development to use it.
The basic concepts have remained the same up to current versions: First and foremost, the object model and index, key features that distinguish Git from other VCS.
The Unix philosophy of “one tool, one job” is also consistently applied here; the subcommands of Git are each independent, executable programs or scripts.
Even in the 2.0 version there are still (as at the beginning of the development) some subcommands with shell scripts implemented (e.g. git pull).
Linus Torvalds himself does hardly any programming on Git these days; a few months after the first release, Junio C. Hamano took over as maintainer.
Not only the revolutionary approach of Git, but also the fact that the entire kernel development was migrated to Git quickly and successfully has given Git a steep rise. Many projects, some of them very large, now use Git and benefit from the flexibility it has gained.
Who Is This Book Intended For?
The book is aimed at both professional software developers and users who want to work on small scripts, web pages or other documents or who want to get actively involved in an (open source) project. It teaches basic version control techniques, introduces the basics of Git, and explains all the major use cases.
Work that you don’t manage with a version control system is work that you might have to do again—whether it’s because you accidentally delete a file or consider parts obsolete that you need later. For any form of productive text and development work, you need a tool that can record and manage changes to files. Git is flexible, fast, and equally suited for small projects by individuals or large projects involving hundreds of developers, such as the Linux kernel.
Developers who already use a different version control system can benefit from switching to Git. Git allows a much more flexible way of working and is in many respects not as restrictive as comparable systems. It supports true merging and guarantees the integrity of managed data.
Git also benefits open source projects, because each developer has his or her own repository, which prevents disputes over commit privileges. Git also makes it much easier for newcomers to get started.
Although most of the examples and techniques presented refer to source code, there is no fundamental difference to managing documents written in LaTeX, HTML, AsciiDoc or related formats.
How to Read the Book?
Ch. 1, Introduction and First Steps gives a brief overview: How do you initialize a git repository and manage files in it? It also covers the most important configuration settings.
Ch. 2, The Basics covers two key concepts of Git: the index and the object model. Along with other important commands that are introduced there, understanding these two concepts is essential to the safe use of Git.
Ch. 3, Practical Version Control discusses practical aspects of version control. In particular, it covers the branches and merges that are so central to Git. It also discusses how to resolve merge conflicts in detail.
Ch. 4, Advanced Concepts discusses advanced concepts, with a special focus on the Rebase command, an essential tool for any git professional. Other important commands follow, including Blame, Stash, and Bisect.
Only Ch. 5, Distributed Git looks at the distributed aspects of Git: how to share changes between repositories, how developers can collaborate. Then Ch. 6, Workflows provides an overview of strategies for coordinating development work in a project.
We recommend that you read at least the first five chapters in a row. They describe all the important concepts and techniques for using Git safely in large projects. You can read the following chapters in any order, depending on your interests and needs.
Ch. 7, Git Servers covers installation and maintenance of Git services: two web-based repository browsers and access management for hosted repositories using Gitolite.
Ch. 8, Git Automation summarizes various aspects of automation: How to write hooks and custom Git commands, and how to rewrite the complete version history if necessary.
Finally, Ch. 9, Interacting with Other Version Control Systems discusses migration from other systems to Git. The focus here is on converting existing Subversion repositories, and on the ability to talk to Subversion from within Git.
The appendices deal with the installation and integration of Git into the shell. An outlook on the hosting service Github and a detailed description of the structure and maintenance mechanisms of a git repository provide further background information.
Conventions
The examples are only executed on the shell. Even though some editors and IDEs now offer quite a good Git integration, and even though there are a lot of graphical front-ends for Git, you should first learn the basics with the real Git commands.
The shell prompt is a single dollar sign ($); keyboard input is printed in semi-bold, like this
$ git status
To find your way around the shell faster and better, we strongly recommend adding git functionality to the shell, such as displaying the branch in the prompt (see Ch. 10, Shell Integration).
Unless otherwise noted, we refer to Git version 2.0. The examples all run with English local settings.
Newly introduced terms are written in italics.
Installation and “The Git-Repository”
The installation of Git is described in detail in App. A, Installation. Some examples use the Git source repository, the repository where Git is actively developed. This repository is also called Git-via-Git or git.git.
After you have installed Git, you can download the repository with the following command
$ git clone git://git.kernel.org/pub/scm/git/git.git
The process takes a few minutes, depending on the connection speed and server load.
Documentation and Help
A comprehensive documentation of Git is available in the form of pre-installed man pages.
Almost every subcommand has its own man page, which you can call in three equivalent ways, here for the git status command, for example:
$ git help status $ git status --help $ man git-status
On the Git website[1] you can also find links to the official tutorial and other free documentation.
A large, vibrant community has formed around Git. The Git mailing list[2] is the lynchpin of the development: patches are sent in, new features are discussed, and questions about using Git are answered. However, the list, with sometimes more than 100 emails a day, some of them very technical, is only suitable for beginners to a limited extent.
The Git Wiki[3] contains documentation as well as an extensive link collection of tools based on Git[4] and FAQs[5].
Alternatively, the #git IRC channel on the Freenode network provides a place to get rid of questions not already answered in the FAQs or documentation.
For those switching from the Subversion environment, the Git-SVN Crash Course[6] is recommended, a comparison of Git and Subversion commands that will help you transfer your Subversion knowledge to the Git world.
Also worth mentioning is Stack Overflow[7], a platform by programmers for programmers, on which technical issues, including Git, are discussed.
Downloads and Contacts
The sample repositories of the first two chapters and a collection of all longer scripts are available for download at http://gitbu.ch/.
If you have any comments, please contact us by e-mail at one of the following addresses: kontakt@gitbu.ch, valentin@gitbu.ch or julius@gitbu.ch.
Acknowledgements
First of all, we’d like to thank all the developers and maintainers of the Git project as well as the mailing list and the IRC channel.
Many thanks to Sebastian Pipping and Frank Terbeck for comments and tips. Special thanks to Holger Weiß for his review of the manuscript and helpful ideas. We thank the entire Open Source Press Team for the good and efficient cooperation.
Our thanks go especially to our parents, who have always supported and encouraged us.
Valentin Haenel and Julius Plenz — Berlin, June 2011
Preface to the 2nd Edition
In the 2nd edition, we have limited ourselves to carefully recording the changes in the use of Git that were introduced up to version 2.0 — in fact, many commands and error messages are now more consistent, so that in some places this represents a significant simplification of the text. Inspired by questions from Git training courses and our own experience, new hints on problems, solutions, and interesting features are included.
We thank all those who sent in corrections to the first edition: Philipp Hahn, Ralf Krüdewagen, Michael Prokop, Johannes Reinhold, Heiko Schlichting, Markus Weber.
Valentin Haenel and Julius Plenary Session — Berlin, September 2014
Preface to the Creative Commons Edition
The publisher Open Source Press, who initially convinced us to write this book at all and published it over the past few years, has ceased operations as of 31.12.2015 and has transferred all rights to the published texts back to the authors. We especially thank Markus Wirtz for the always good and productive collaboration that has connected us over many years.
Due to mainly very positive feedback on this text we decided to make it freely available under a CreativeCommons-License.
Valentin Haenel and Julius Plenz — Berlin/Sydney, January 2016