GIT

Git usage

Creating a repository

To begin using Git, we have first to create a repository, also known as “repo”. For that, in the directory where we want to have the repository, we have to execute:

git init

We have a Git repository! Note that a folder named .git has been created. The repository will be the directory where the .git folder is placed. This folder is the repository metadata, an embedded database. It’s better not to touch anything inside it while you are not familiarized with Git.

Creating the history: commits

Git constructs the history of the repository with commits. A commit is a full snapshot of the repository, that is saved in the database. Every state of the files that are committed, will be recoverable later at any moment.

When doing a commit, we have to choose which files are going to be committed; not all the repository has to be committed necessarily. This process is called staging, where files are added to the index. The Git index is where the data that is going to be saved in the commit is stored temporarily, until the commit is done.

Let’s see how it works.

We are going to create a file and add some content to it, for example:

echo 'My first commit!' > README.txt

Adding this file, the status of the repository has changed, since a new file has been created in the working directory. We can check for the status of the repository with the status option:

git status

Which, in this case, would generate the following output:

On branch master

 Initial commit

 Untracked files:

  (use "git add <file>..." to include in what will be committed)

         README.txt

 nothing added to commit but untracked files present (use "git add" to track)

What Git is saying is “you have a new file in the repository directory, but this file is not yet selected to be committed“.

If we want to include this file the commit, remember that it has to be added to the index. This is made with the addcommand, as Git suggests in the output of status :

git add README.txt

Again, the status of the repository has changes:

On branch master

Initial commit

Changes to be committed:

  (use "git rm --cached <file>..." to unstage)

        new file:   README.txt

Now, we can do the commit!

git commit

Now, the default text editor will be shown, where we have to type the commit message, and then save. If we leave the message empty, the commit will be aborted.

Additionally, we can use the shorthand version with -m flag, specifying the commit message inline:

git commit -m 'Commit message for first commit!'

We can add all the files of the current directory, recursively, to the index, with .:

git add .

Note that the following:

echo 'Second commit!' > README.txt

git add README.txt

echo 'Or is it the third?' > README.txt

git commit -m 'Another commit'

Would commit the file with 'Second commit!' content, because it was the one added to the index, and then we changed the file of the working directory, not the one added to staging area. To commit the latest change, we would have to add again the file to the index, being the first added file overwritten.

Git identifies each commit uniquely using SHA1 hash function, based on the contents of the committed files. So, each commit is identified with a 40 character-long hexadecimal string, like the following, for example: de5aeb426b3773ee3f1f25a85f471750d127edfe. Take into account that the commit message, commit date, or any other variable rather than the committed files’ content (and size), are not included in the hash calculation.

So, for our first two commit, the history would be the following:

Git shortens the checksum of each commit to 7 characters (whenever it’s possible), to make them more legible.

Each commit points to the commit it has been created from, being this called the “ancestor”.

Note that HEAD element. This is one of the most important element in Git. The HEAD is the element that points to the current point in the repository history. The contents of the working directory will be those that belong to the snapshot the HEAD is pointing to.

We will see this HEAD more in detail later.

Tips for creating good commit messages

The commit message content is more important that it may seem at first sight. Git allows to add any kind of explanation for any change we made, without touching the source code, and we should always take advantage of this.

For the message formatting, there’s an unwritten rule known as the 50/72 rule, which is so simple:

One first line with a summary of no more than 50 characters.

Wrap the subsequent explanations in lines of no more than 72 characters.

This is based on how Git formats the output when we are reviewing the history.

But, more important than this, is the content of the message itself. The first thing that comes to mind to write are the changes that have been made, which is not bad at all. But the commit object itself is a description of the changes that have been made in the source code. To make the commit messages useful, you should always include the reason that motivated the changes.

                                                                                                                                                     Next >>