Preface
Whenever several people work together on a software project, a system is needed to store all the changes made in a traceable way. Such a version control system must also give all developers access to the entire project. Each programmer knows what the others have done recently; developers can try out the code of the others and test the code's interaction with their own changes.
In the past, many version control systems were used, such as Concurrent Versions System (CVS), Apache Subversion (SVN), or Microsoft Visual SourceSafe (VSS). In the last decade, however, Git has become the de facto standard.
The GitHub web platform played a significant role in this success, making learning and using Git much easier. Countless open-source projects use the free GitHub offering for project hosting. Commercial customers who didn't want to publish their source code pay for this service. GitHub is not the only Git platform, of course: Major competitors include GitLab, Azure DevOps Services, and Bitbucket. Microsoft bought GitHub in 2018 for $7.5 billion. Unlike other acquisitions, this development hasn't hurt GitHub's popularity so far.
The Story of Git
Git came into being because Linus Torvalds needed a new version management system for the further development of the Linux kernel. The developer community had previously used the BitKeeper program. Torvalds was basically satisfied with the program, but a license change necessitated a switch. Of the open-source programs available at the time, none met his high standards.
So, the Linux chief developer briefly stopped his main work and created the basic framework for Git in just two weeks. The name Git stands for stupid or moron, and the help page man git also refers to the program as the stupid content tracker.
That this definition was an understatement became clear only gradually, long after Torvalds had given up on further development of Git and put it out of his hands. Not only did kernel developers quickly and easily switch their work to Git, but in the years that followed, more and more software projects outside the open-source world switched to Git as well.
Git made its final breakthrough when web platforms such as GitHub and GitLab became established. These websites simplify the hosting of Git projects enormously and have become an indispensable part of everyday Git life. (Even the Linux kernel is now on GitHub!)
Ironically, Torvalds' main goal in designing Git was to create a decentralized version control system. But the centralized approach of GitHub and others made Git attractive for developers outside the guru league.
Some rate the importance of Git as highly as that of Linux. Torvalds has thus twice succeeded in completely turning the software universe on its head.
Everyone Uses It, but No One Understands It
With all the enthusiasm, Git was clearly designed by professionals for professionals. We don't want to give you the impression in this book that Git is easy because it isn't. You'll need to keep in mind the following considerations:
-
Often, more than one way exists to reach a goal. For readers already familiar with Git, this idea is useful, but if you're just learning Git, this diversity can be confusing.
-
Many open-source projects are accused of being poorly documented. You really can't say that about Git. On the contrary, every git command and every possible application is explained in man pages as well as on the website (https://git-scm.com/docs) in such granularity and with so many conceivable special cases that you can get lost in the details.
-
Complicating matters further, some terms carry many different meanings, and easily confused subcommands might perform widely divergent tasks. Some terms have different meanings depending on their context or are used inconsistently in the documentation.
We have a confession: Despite years of using Git, we still learned a lot while writing this book!
About This Book
Of course, you can use Git in a minimalistic way. However, small deviations from the daily routine can then lead to surprising and often incomprehensible side effects or errors.
Every Git beginner knows that feeling when a git command returns an incomprehensible error message: In a cold sweat, you wonder whether you've just permanently destroyed a repository for all your developers and try to find someone to persuade Git to continue working after all with the right commands.
Thus, describing Git without going into depth isn't useful. Only a good understanding of how Git works gives you the confidence you'll need to cleanly fix merge conflicts or other problems.
At the same time, however, we knew that this book could only work if we gave priority to the essential functions. Despite its over 400 pages, this book is not the all-encompassing guide to Git. We cannot consider every single special case or introduce every Git subcommand, no matter how exotic. We've therefore tried to separate the wheat from the chaff in this book.
This book is divided into manageable chapters that you can read as needed, like building blocks:
-
After a short introduction in Chapter 1, we'll introduce the use of Git in Chapter 2 through Chapter 4. We'll focus on the use of Git at the command level and only marginally discuss platforms such as GitHub or other user interfaces (UIs).
For Git beginners, we recommend starting with these first four chapters. Even if you have some Git experience, you should definitely take a few hours to read Chapter 3 and try out some of the techniques we present (merging, rebasing, etc.) in a test repository.
-
The next three chapters introduce the most important Git platforms. Especially for complex projects, these platforms provide useful additional functions, for instance, to perform automatic tests or to implement continuous integration (CI).
Of course, we also show you how to host your own Git repository. With GitLab, Gitea, or Gitolite, this goal can be realized relatively easily.
-
Then, we'll turn from the basics to the practical:
-
In Chapter 8, we'll describe popular patterns for guiding the work of numerous developers into orderly paths (branches) with Git.
-
Chapter 9 focuses on advanced Git features, such as hooks, submodules, subtrees, and two-factor authentication, which are all supported by major Git platforms.
-
Chapter 10 shows how you can use version configuration files (dotfiles) or the entire /etc directory with Git on Linux systems, how to switch a project from SVN to Git, and how to realize a simple website quickly and easily with Git and Hugo.
-
Chapter 11 helps you break the deadlock on hard-to-understand error messages. In this chapter, you'll also find instructions on implementing special requests, for example, removing large files from a Git repository or performing a merge operation on a selected file only.
-
To close the book, Chapter 12 briefly summarizes the most important git commands and their options. In this chapter, we followed the motto "Less is more." Our goal was not a complete reference, but rather a guide to the "essence of Git".
Sample Repositories
Some examples from this book are available on GitHub at the following link:
https://github.com/git-compendium
A Note to Readers
We realize that you may not begin reading this book with great enthusiasm: Perhaps you need to use Git for a project. Your goal might not be Git as such-you want to produce code to drive your project. You may not really have the time or inclination to learn about Git; you just want to know enough to use Git without errors.
We understand that motivation. Nevertheless, we strongly recommend that you invest a few hours more than planned to get to know Git systematically.
We promise you: You'll win this time back later! Poor understanding of Git inevitably means that you'll need...
