Git Essentials - Second Edition

3 (5 reviews total)
By Ferdinando Santacroce
  • Instant online access to over 8,000+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies

About this book

Since its inception, Git has attracted skilled developers due to its robust, powerful, and reliable features. Its incredibly fast branching ability transformed a piece of code from a niche tool for Linux Kernel developers into a mainstream distributed versioning system. Like most powerful tools, Git can be hard to approach since it has a lot of commands, subcommands, and options that easily confuse newcomers.

The 2nd edition of this very successful book will help you overcome this fear and become adept in all the basic tasks in Git. Building upon the success of the first book, we start with a brief step-by-step installation guide; after this, you'll delve into the essentials of Git. For those of you who have bought the first edition, this time we go into internals in far greater depth, talking less about theory and using much more practical examples.

The book serves as a primer for topics to follow, such as branching and merging, creating and managing a GitHub personal repository, and fork and pull requests. You’ll then learn the art of cherry-picking, taking only the commits you want, followed by Git blame. Finally, we'll see how to interoperate with a Subversion server, covering the concepts and commands needed to convert an SVN repository into a Git repository.

To conclude, this is a collection of resources, links, and appendices to satisfy even the most curious.

Publication date:
November 2017


Getting Started with Git

Whether you are a professional or an amateur developer, you've likely heard about the concept of version control. You may know that adding a new feature, fixing a broken one, or stepping back to a previous condition is a daily routine.

This requires the use of a powerful tool that can help you take care of your work, allowing you to move around your project quickly and without friction.

There are many tools for this job on the market, both proprietary and open source. Usually, you will find Version Control Systems (VCS) and Distributed Version Control Systems (DVCS). Some examples of centralized tools are Concurrent Version System (CVS), Subversion (SVN), Team Foundation Server (TFS), and Perforce Helix. While in DVCS, you can find Bazaar, Mercurial, and Git. The main difference between the two families is the constraint—in the centralized system—to have a remote server from which to get and in which to put your files; needless to say, if the network is down, you are in trouble. In DVCS, on the other hand, you can either have or not have a remote server (even more than one), but you can work offline, too. All your modifications are locally recorded so that you can sync them at some other time. Today, Git is the DVCS that has gained more public favor than others, growing quickly from a niche tool to mainstream.

Git has rapidly grown as the de facto source code versioning tool. It is the second famous child of Linus Torvalds, who, after creating the Linux kernel, forged this versioning software to keep track of his million lines of code.

In this first chapter, we will start at the very beginning, assuming that you do not have Git on your machine. This book is intended for developers who have never used Git or only used it a little bit, but who are scared to throw themselves headlong into it.

If you have never installed Git, this is your chapter. If you already have a working Git box, you can quickly read through it to check whether everything is alright.


Foreword to the second edition

Welcome to the second edition of Git Essentials!

This paragraph is dedicated to those who have already read the first edition; here you will find an overview of the changes and new things inside this brand-new edition.

First of all, we listened to your feedback: in Chapters 2Git Fundamentals - Working Locally and Chapter 3Git Fundamentals - Working Remotely we will look at some technical details in more depth, describing more accurately the internals of Git; this entails extra effort on the part of the reader, but in return, he or she will obtain a more mindful understanding of Git architecture that will later help to grasp the commands of this powerful tool.

The Git ecosystem made some really giant steps forward since April 2015, but at its heart, Git is always the same. Here is an incomplete list of new features and improvements:

  • Big improvements for Windows (for example, a fully working credential subsystem, performance enhancements, and so on—see
  • Git Large File Storage (LFS)-an additional tool from GitHub friends (see
  • Git Virtual File System from Microsoft fellows (see
  • git worktree command and functionalities. Worktrees are a feature that was first included in Git 2.5; they let you check out and work on multiple repository branches in different directories simultaneously-see
  • A lot of improvements and new options for common commands, too many to cite them all.

So the aim of this book is to get started with versioning and learn how to do it proficiently.

Let's start!


Installing Git

Git is open source software. You can download it for free from, where you will find a package for all the most common environments (GNU-Linux, macOS and Windows). At the time of writing this book, the latest version of Git is 2.11.0.

Installing Git on GNU-Linux

If you are a Linux user, you may have Git out of the box.
If not, you can use the distribution package manager to download and install it; an apt-get install git command or equivalent will provide you Git and all the necessary dependencies in seconds, as shown in the following image:

Installing Git on Kubuntu

Installing Git on macOS

There are several ways to install Git on macOS. The easiest way is to install the Xcode command line tools. Since Mavericks (10.9), you can do this simply by trying to run git from the terminal for the very first time. If you don't have it installed already, it will prompt you to install it, as shown in the following image:

Clicking on the Install button will fire the installation process.

If you want a more up-to-date version, you can also install it via the *.dmg binary installer, downloaded from (it says mavericks in the file name, but just ignore that). Beware the macOS policies while installing packages downloaded from the Internet; to allow execution, you need to hold down CTRL and click on the package icon to open it:

Hold down CTRL and click to let macOS prompt you to open the package

After this, the installation will be very easy-it's just a matter of clicking on the Continue button and following the steps represented in the following screenshot:

Let's start the installation process

Click on the Continue button and then go on; a window like the one shown in the following image will appear:

Here you can change the installation location, if you need; if in doubt, simply click Install

Click now on the Install button to start the installation. After a few seconds, the installation will be completed:

Installation complete

Installing Git on Windows

While clicking on the Download button on, you will automatically download Git in either the x86 or the x64 variant. I won't go into too much detail about the installation process itself, as it is trivial; I will only provide a few recommendations in the following screenshots:

Enabling Windows Explorer integration is generally useful; you will benefit from a convenient way to open a Git prompt in any folder by right-clicking on the contextual menu.

You should also enable Git to be used in the classic DOS command prompt, as shown in the following screenshot:

Git is provided with an embedded, Windows-compatible version of the famous Bash shell (see, which we will use extensively. By doing this, we will also make Git available to third-party applications, such as GUIs and so on. It will come in handy when we give some GUI tools a try.

Use defaults for line endings. This will protect you from future annoyances while working on multiplatform repositories:

Now it's time to choose a terminal emulator for Git; I recommend using MinTTY (see, as it is a very good shell, fully customizable and user friendly:

Now, let's look at some new stuff from the latest Git releases-that is file system caching, the Git Credential Manager, and symbolic links:

File system caching has been considered experimental until Git for Windows v2.7.4 (March 18, 2016), but now it is stable, and since Git 2.8 this feature is enabled by default. This is a Windows-only configuration option, and allows Git to be quicker when dealing with the underlying read/write operations. I recommend that you enable it for optimal performance.

Git Credential Manager (see is included in the Git for Windows installer since v2.7.2 (February 23, 2016). Thanks to Microsoft, today, you can deal with Git users and passwords as easily as you can on other platforms. It requires .NET framework v4.5 or later, and perfectly integrates even with Visual Studio (see and the GitHub for Windows (see GUI. I recommend that you enable it, as it saves some time while working.

Symbolic links is a feature that Windows has lacked from the beginning, and even when they were introduced in Windows Vista, they have highlighted many incompatibilities with with Unix-like symlinks.

Anyway, Git and its Windows subsystem can handle them (with some limitations), so, if needed, you can try to install this feature and enable it in configuration options (they are disabled by default). For now, however, the best thing is to not use them at all in your repository if you need to work on the Windows platform. You can find more info at

Git for Windows v2.10.2 (November 2 2016) introduced a new, built-in difftool that promises quicker diffs. I use it on a daily basis, and I find it quite stable and fast. Enable it if you want give it a try, but this is not mandatory for the purposes of this book.

Git for Windows will install it in the default Program Files folder, as all the Windows programs usually do.

At the end of the process, we will have Git installed, and all its *nix friends will be ready to use it.

Please keep an eye on the Release Notes to see what's new in the latest release.


Running our first Git command

From now on, as a matter of convenience, we will use Windows as our platform of reference. Our screenshots will always refer to that platform. In any case, all the Git main commands we will use will work on the platforms we have previously mentioned anyway.

It's time to test our installation. Is Git ready to rock? Let's find out!

Using shell integration, right-click on an empty place on the desktop and choose the new menu item Git Bash Here. It will appear as a new MinTTY shell, providing you a Git-ready bash for Windows:

This is a typical Bash prompt: we can see the user, nando, and the host, computer. Then there's a MINGW64 string, which refers to the actual platform we are using, called Minimalist GNU for Windows (see, and at the end we find the actual path, in a more *nix fashion, /c/Users/nando. Later, we will look at this argument in more detail.

Now that we have a new, shiny Bash prompt, simply type git (or the equivalent, git --help), as shown in the following screenshot:

If Git has been installed correctly, typing git without specifying anything else will result in a short help page, with a list of common commands (if not, try reinstalling Git).

So, we have Git up and running! Are you excited? Let's begin to type!

Making presentations

Git needs to know who you are. This is because in Git, every modification you make in a repository has to be signed with the name and email of the author. So, before doing anything else, we have to tell Git this information.

Type these two commands:

Using the git config command, we set up two configuration and Starting from now, Git will use them to sign your commits in all your repositories. Do not worry about it for now; in the next few chapters, we will explore the Git configuration system in more detail.

Setting up a new repository

The first step is to set up a new repository. A repository is a container for your entire project; every file or subfolder within it belongs to that repository, in a consistent manner. Physically, a repository is nothing other than a folder that contains a special .git folder, the folder where the magic happens.

Let's try to make our first repository. Choose a folder you like (for example, C:\Repos\MyFirstRepo), and type the git init command, as shown here:

As you can see, I slightly modified the default Git Bash prompt to better fit the need of the demoing commands; I removed the user and host, and added an incremental number to every command we type so that it will be simpler for me to refer to it while explaining, and for you to refer to it while reading.

Let's get back on topic. What just happened inside the MyFirstRepo folder? Git created a .git subfolder. The subfolder (normally hidden in Windows) contains some other files and folders, as shown in the next screenshot:

At this point in time, it is not important for us to understand what is inside this folder. The only thing you have to know is that you do not have to touch it, ever! If you delete it or if you modify the files inside by hand, you could get into trouble. Have I frightened you enough?

Now that we have a repository, we can start to put files inside it. Git can trace the history of any type of file, text-based or binary, small or large, with the same efficiency (more or less; large files are always a problem).

Adding a file

Let's create a text file, just to give it a try:

And now what? Is that all? No! We have to tell Git to put this file in your repository, explicitly. Git doesn't do anything that you don't want it to do. If you have some spare or temp files in your repository, Git will not take care of them, but will only remind you that there are some files in your repository that are not under version control (in the next chapter, we will see how to instruct Git to ignore them when necessary).

Okay, back to the topic. I want file.txt under the control of Git, so let's add it, as shown here:

The git add command tells Git that we want it to take care of that file and check it for future modifications.

In response to this command, it could happen that you will see this response message from Git:

warning: LF will be replaced by CRLF in file.txt.

The file will have its original line endings in your working directory.

This is because of the option that we selected when installing Git: Checkout Windows-style, commit Unix-style line endings. Don't worry about it for the moment; we will deal with it later.

Now, let us see if Git obeyed us.

Using the git status command, we can check the status of the repository, as shown in this screenshot:

As we can see, Git has accomplished its work as expected. In this image, we can read words such as branch, master, commit, and unstage. We will look at them briefly, but for the moment, let's ignore them: The purpose of this first experiment is overcome our fear and start playing with Git commands; after all, we have an entire book in which to learn the significant details.

Committing the added file

At this point, Git knows about file.txt, but we have to perform another step to fix the snapshot of its content. We have to commit it using the appropriate git commit command. This time, we will add some flavor to our command, using the --message (or -m) subcommand, as shown here:

With the commit of file.txt, we have finally fired up our repository. Having done the first commit (also known as the root-commit, as you can see in the screenshot), the repository now has a master branch with a commit inside it. We will play with branches in the forthcoming chapters. Right now, think of it as a path of our repository, and keep in mind that a repository can have multiple paths that often cross each other.

Modifying a committed file

Now, we can try to make some modifications to the file and see how to deal with it, as shown in the following screenshot:

As you can see, the Bash shell warns us that there are some modifications painting the name of the modified files in red. Here, the git status command informs us that there is a file with some modifications, and that we need to commit it if we want to save this modification step in the repository history.

However, what does no changes added to commit mean? It is simple. Git makes you take a second look at what you want to include in the next commit. If you have touched two files but you want to commit only one, you can add only that one.

If you try to commit by skipping the add step, nothing will happen (see the following screenshot). We will analyze this behavior in depth in the next chapter.

So, let's add the file again for the purpose of getting things ready for the next commit:

Okay, let's make another commit, this time, avoiding the --message subcommand. Type git commit and hit the Enter key:

Fasten your seatbelts! You are now entering in a piece of code history!

What is that? It's Vim (Vi IMproved), an ancient and powerful text editor, used even today by millions of people. You can configure Git to use your own preferred editor, but if you don't do it, this is what you have to deal with. Vim is powerful, but for newcomers, it can be a pain to use. It has a strange way of dealing with text. To start typing, you have to press I for inserting text, as shown in the following screenshot:

Once you have typed your commit message, you can press Esc to get out of editing mode. Then, you can type the :w command to write changes and the :q command to quit. You can also type the command in pairs as :wq, as we do in this screenshot, or use the equivalent :x command:

After that, press Enter and another commit is done, as shown here:

Note that when you exit from Vim, Git automatically dispatches the commit, as you can see in the preceding screenshot.

Well done! Now, it's time to recap.



In this chapter, you learned that Git is not so difficult to install, even on a non-Unix platform, such as Windows.

Once you have chosen a directory to include in a Git repository, you can see that initializing a new Git repository is as easy as executing a git init command. For now, don't worry about saving it on a remote server and so on. It's not mandatory to save it; you can do this when you need, preserving the entire history of your repository. This is a killer feature of Git and DVCS in general. You can comfortably work offline and push your work to a remote location when the network is available, without any hassle.

Lastly, we discovered one of the most important character traits of Git: it will do nothing if you don't mention it explicitly. You also learned a little bit about the add command. We were obliged to perform a git add command for a file when we committed it to Git for the very first time. Then, we used another command when we modified it. This is because if you modify a file, Git does not expect that you want it to be automatically added to the next commit (and it's right to assume this, I'd say).

In the next chapter, we will look at some fundamentals of Git.

About the Author

  • Ferdinando Santacroce

    Ferdinando Santacroce is a developer, author, and trainer who loves learning new things. As a software developer, Ferdinando has mainly worked on the .NET platform using C#, bridging the gap between old-style systems and new technologies. Over the span of his career, he has allowed some COBOL applications to talk to remote services, databases, and electronic devices such as cash handlers, scanners, and electronic shelf labels.

    At the moment, he is committed to helping the largest energy player in Italy to face new challenges in the market by developing Java and JavaScript-based applications.

    Other than this, he's focusing on continuous improvement and agile movement, which he follows with great care, in conjunction with XP foundations and lean manufacturing. He's one of the organizers of Italian Agile Days, the most famous and appreciated conference in the Italian Agile panorama.

    Ferdinando loves to share ideas with other professionals and to speak at public conferences; every time he has, he has learned something new.

    He enjoys writing as well. After a hiatus of a few years, he has started blogging again about his work and passions, which, according to him, are more or less the same thing.

    Most of what he has learned over the years has been with the help of his friends and colleagues. Other than working within the same team or on the same code base, they have encouraged him to read books and attend inspiring conferences, such as XP Days, Italian Agile Days, and others that have helped his growth.

    Browse publications by this author

Latest Reviews

(5 reviews total)

Recommended For You

Book Title
Access this book, plus 8,000 other titles for FREE
Access now