Let's continue where we left off in Chapter 1, Getting Started with Git. Walk into C:ReposMyFirstRepo and start a new Bash shell using the right-click shortcut. Now, use the git log command to see the history of our repository, as shown in this screenshot:
The git log command is very useful and powerful. With this command, we can get all the commits that we did one by one, each one with its most important details. It's now time to become more familiar with them.
Commits are the building blocks of a repository. Every repository is nothing more than an ordered sequence of commits. If you have a math background, you have probably already identified an acyclic direct graph in it.
Every time we commit something, Git wraps all the files included in a binary blob file. This is one of the most important characteristics of Git. While other versioning systems save files one by one (perhaps using deltas), Git produces a snapshot every time you commit, storing all the files you have included in it. You can assume that a snapshot is a commit, and vice versa.
The commit hash is the 40-character string we saw in logs. This string is the plate of the commit, the way we can refer to it unequivocally. We will not fail to use it in our little exercises.
Git is for collaborating, too. So, it is important that every author signs every commit it does to make it clear who did what.
In every commit, you will find the author's friendly name and their e-mail to get in touch with them when necessary. If you are not happy with the actual author you see, change it with the git config command, as shown here:
Configuring Git is quite simple. You have to know the name of the object to configure (user.name in this example) and give it a git config <object> "<value>" command. To change the e-mail, you have to change the user.email configuration object.
If you want to see the value of an object, simply type git config <object> and press Enter to get it.
There are three configuration levels: global, user, and repository. We will soon deal with Git configuration in more detail.
In the first chapter, we made two commits, and every time, we added a commit message. Adding a commit message is not only a good practice, it is mandatory. Git would not accept commits without a relative commit message. This is a thing I really appreciate. Let me explain it briefly.
In other versioning control systems, such as SVN, commit messages are optional. Developers, we all know, are lazy people. When they are in a hurry or under stress, the temptation to commit code without telling what feature of the software they are going to add, modify, improve or delete is strong. In no time, you build a mute repository with no change history, and you have to deal with commits that are difficult to understand. In other words, welcome to hell.
At this point, probably, you are wondering if there is a way to add more than one file at a time. Of course there is! With git add --all (-A), you add all of the files you have in your working directory to the index. You can also use <filepattern> to add only certain types of files; for example, with git add *.txt, you can add all text files to the index.
Often, we work with temp or personal files that we don't want to commit in the repository. So, when you commit all files, it is useful to skip certain kinds of files or folders.
To achieve this result, we can create a .gitignore file in the repository. Git will read it and then skip the files and folders we listed inside it.
Let's try to do this in our repository, C:ReposMyFirstRepo. Perform the following steps:
- Browse to
C:ReposMyFirstRepo. - Create a
.gitignorefile using your preferred editor. - Put this text inside it:
# === This is a sample of .gitignore file === # Ignore temp files *.tmp
- Save the file.
- Add the file to the index.
- Commit the
.gitignorefile. - Create a temp file
fileToIgnore.tmpwith a simpletouchcommand. - Try to add all of the files in your working directory to the index and verify that Git will not add anything.
Note that .gitignore file is not retroactive. If you have added some *.tmp files to the index before introducing the .gitignore file, they will stay under revision control. You have to remove them manually if you want to skip them.
The syntax of a .gitignore file is quite simple. Lines starting with # are comments, and they will be ignored. In each line of the file, you can add something to skip. You can skip a single file or folder, certain files by extension, as we did with *.tmp files, and so on.
For the complete syntax of .gitignore see http://git-scm.com/docs/gitignore.
We said that commits have an ID and a lot of other useful information bundled with binary blobs of files included. Sometimes, we want to mark a commit with a tag to place a milestone in our repository. You can achieve this by simply using the git tag –a <tag name> command, using –m to type the mandatory message:
$ git tag –a MyTagName –m "This is my first tag"
Tags will become useful in the future to keep track of important things such as a new software release, particular bug fixes, or whatever you want to put on evidence.