Part 6
Working with the Repository’s History

You’ve learned all the basics, as well as some of the more complex topics in Git. It’s time to start looking at all that history you’ve been building up and put the code in the context it was created in.

Your repository is a vault of all the changes you and your team have made to your project. Git tracks all of those changes and their commit messages, making them viewable and searchable via the log.

The log is a reverse chronological view of each commit. By default, it shows you the commit ID, the author, the committer (if that person is different from the author), the date, and the log message. You can show more (or less) in that output.

The power of Git’s log feature is directly related to how your project handles commit messages. The more information you add to your commit message, the more valuable the log is to your developers.

Git convention for commit messages is to break the messages into two parts. Start with a one-line “subject” that tersely describes the change that was made, and then follow it with a more in-depth “body” that describes the change in plain text. The rule of thumb is to explain the change like you’re explaining it to another developer. Let the code speak for itself, but make sure to include reasons for the change and explain any potentially odd choices.

Covered in this part:

• We start with the log in Task 30, ​Viewing the Log​. You’ll learn how to view the log in a couple of different formats and how to understand the information it displays.

• Once you understand the basics of querying Git’s log, Task 31, ​Filtering the Log Output​ walks you through filtering those results through Git’s revisions and ranges.

• Each commit tracks changes between files. Those changes are described as diffs. You’ll learn how to view Git’s diffs in Task 32, ​Comparing Differences​ so you can see changes across different commits.

• Everyone loves statistics. Well, at least managers do. In addition to the excellent diffs and logs that Git provides, it also gives you the ability to generate some statistics on the changes your repository is tracking. You’ll learn how to use these tools in Task 33, ​Generating Statistics About Changes​.

• Finally, we wrap up this part with a section on blame. The logs provide us with excellent information on individual changes. In Task 34, ​Assigning Blame​, you learn how inspect information about each line of a file. It’s excellent for assigning blame—er, praise—on the other members of your team when you find their excellently unique code.

Now, let’s jump into the basic display of your repository’s history: the log.