In this second edition of Git Essentials, I slightly changed my approach in explaining how Git works; instead of explaining with words and figures, this time I want to show you how Git works internally with only the help of the shell, allowing you to follow all the steps on your computer and hoping that these will be clear enough for you to understand.

Once you know the fundamentals of the Git working system, I think the rest of the commands and patterns will be clearer, allowing you to accomplish proficiently your daily work, getting out of trouble when needed.

So, it's time to start digging inside the true nature of Git; in this chapter, we will get in touch with the essence of this powerful tool.

In Chapter 1, Getting Started with Git, we created an empty folder (in C:\Repos\MyFirstRepo) and then we initialized a new Git repository, using the git init command.

Let's create a new repository to refresh our memory and then start learning a little bit more about Git.

In this example, we use Git to track our shopping list before going to the grocery; so, create a new grocery folder, and then initialize a new Git repository:

[1] ~
$ mkdir grocery

[2] ~
$ cd grocery/

[3] ~/grocery
$ git init
Initialized empty Git repository in C:/Users/san/Google Drive/Packt/PortableGit/home/grocery/.git/

As we have already seen before, the result of the git init command is the creation of a .git folder, where Git stores all the files it needs to manage our repository:

[4] ~/grocery (master)
$ ll
total 8
drwxr-xr-x 1 san 1049089 0 Aug 17 11:11 ./
drwxr-xr-x 1 san 1049089 0...

Okay, now we know there are different Git objects, and we can inspect inside them using some plumbing commands. But how and where does Git store them?

Do you remember the .git folder? Let's put our nose inside it:

[20] ~/grocery (master)
$ ll .git/
total 13
drwxr-xr-x 1 san 1049089   0 Aug 18 17:22 ./
drwxr-xr-x 1 san 1049089   0 Aug 18 17:15 ../
-rw-r--r-- 1 san 1049089 294 Aug 17 13:52 COMMIT_EDITMSG
-rw-r--r-- 1 san 1049089 208 Aug 17 13:51 config
-rw-r--r-- 1 san 1049089  73 Aug 17 11:11 description
-rw-r--r-- 1 san 1049089  23 Aug 17 11:11 HEAD
drwxr-xr-x 1 san 1049089   0 Aug 18 17:15 hooks/
-rw-r--r-- 1 san 1049089 217 Aug 18 17:22 index
drwxr-xr-x 1 san 1049089   0 Aug 18 17:15 info/
drwxr-xr-x 1 san 1049089   0 Aug 18 17:15 logs/
drwxr-xr-x 1 san 1049089   0 Aug 18 17:15 objects/
drwxr-xr-x 1 san 1049089   0 Aug 18 17:15...

Now it's time to investigate another well-known difference between Git and other versioning systems. Take Subversion as an example: when you do a new commit, Subversion creates a new numbered revision that only contains deltas between the previous one; this is a smart way to archive changes to files, especially among big text files, because if only a line of text changes, the size of the new commit will be much smaller.

Instead, in Git even if you change only a char in a big text file, it always stores a new version of the file: Git doesn't do deltas (at least not in this case), and every commit is actually a snapshot of the entire repository.

At this point, people usually exclaim: "Gosh, Git waste a large amount of disk space in vain!". Well, this is simply untrue.

In a common source code repository, with a certain amount of commit...

It's time to summarize all the concepts illustrated since now.

An image, as they say, is worth a thousand words, so here you can find a picture representing the actual state of our repository, thanks to the git-draw tool (https://github.com/sensorflo/git-draw):

In this graphic representation, you will find a detailed diagram that represents the current structure of the newly created repository; you can see trees (yellow), blobs (white), commits (green), and all relationships between them, represented by oriented arrows.

Note how the direction of the arrow joining the commit comes from the second commit and goes to the first, or from descendant to its ancestor; it may seem a detail, but it is important that graphic representations such as these are properly indicated in order to correctly highlight the relationship that binds the commits between them (it is always...

In the previous section, we have seen that a Git repository can be imagined as a tree that, starting from a root (the root-commit), grows upward through one or more branches.

These branches are generally distinguished by a name. In this Git is no exception; if you remember, the experiments conducted so far led us to commit to the master branch of our test repository. Master is precisely the name of the default branch of a Git repository, somewhat like trunk is for Subversion.

But Subversion analogies end here: we will now see how Git handles branches, and for Subversion users it will be a little surprising.

In Git, a branch is nothing more than a label, a mobile label placed...

Until now, we have barely named the staging area (also known as an index), while preparing files to make a new commit with the git add command.

Well, the staging area purpose is actually this. When you change the content of a file, when you add a new one or delete an existing one, you have to tell Git what of these modifications will be part of the next commit: the staging area is the container for this kind of data.

Let's focus on this right now; move to the master branch, if not already there, then type the git status command; it allows us to see the actual status of the staging area:

[1] ~/grocery (master)
$ git status
On branch master
nothing to commit, working tree clean

Git says there's nothing to commit, our working tree is clean. But what's a working tree? Is it the same as the working directory we talked about...

Now I want to tell you something about the git rebase command; a rebase is a common term while using a versioning system, and even in Git this is a hot topic.

Basically, with git rebase you rewrite history; with this statement, I mean you can use rebase command to achieve the following:

• Combine two or more commits into a new one
• Discard a previous commit you did
• Change the starting point of a branch, split it, and much more

One of the widest uses of the git rebase command is for reordering or combining commits. For this first approach, imagine you have to combine two different commits.

Suppose we erroneously added half a grape in the shoppingList.txt file, then the other half, but at the end...

Yes, I know, probably there's a thought on your mind since we start playing with branches: why he doesn't talk about merging?.

Now the moment has arrived.

In Git, merging two (or more!) branches is the act of making their personal history meet each other. When they meet, two things can happen:

• Files in their tip commit are different, so some conflict will rise
• Files do not conflict
• Commits of the target branch are directly behind commits of the branch we are merging, so a fast-forward will happen

In the first two cases, Git will guide us assembling a new commit, a so-called merge commit; in the fast-forward case instead, no new commit is needed: Git will simply move the target branch label to the tip commit of the branch we are merging.

Let's give it a try.

We can try to merge the melons branch into the master one; to do so, you have to check...