So far we have been committing snapshots of your project and switching between different isolated contexts, but what if we've forgotten how we've got to where we are? Or what if we want to know how one branch differs from another? Git provides a tool that shows you all the commit messages that have lead up to the snapshot you are currently on, which is called git log.
To understand the log command, you have to understand what information is stored when you run the git commit command to store a snapshot. In addition to the manifest of files and commit message and information about the person who committed it, Git also stores the commit that you based this snapshot on. That is, if you clone a project, what was the snapshot that you modified to get to the snapshot that you saved? This is helpful to give context to how the project got to where it is and allows Git to figure out who changed what. If Git has the snapshot you save and the one you based it on, then it can automatically figure out what you changed. The commit that a new commit was based on is called the "parent".
To see a chronological list of the parents of any branch, you can run git log when you are in that branch. For example, if we run git log in the Hello World project that we have been working on in this section, we'll see all the commit messages that we've done.
$ git log commit 8d585ea6faf99facd39b55d6f6a3b3f481ad0d3d Merge: 3cbb6aa 3ac015d Author: Scott Chacon <schacon@> Date: Fri Jun 4 12:59:47 2010 +0200 Merge branch 'fix_readme' Conflicts: README commit 3cbb6aae5c0cbd711c098e113ae436801371c95e Author: Scott Chacon <schacon@> Date: Fri Jun 4 12:58:53 2010 +0200 fixed readme title differently commit 3ac015da8ade34d4c7ebeffa2053fcac33fb495b Author: Scott Chacon <schacon@> Date: Fri Jun 4 12:58:36 2010 +0200 fixed readme title commit 558151a95567ba4181bab5746bc8f34bd87143d6 Merge: b7ae93b 3467b0a Author: Scott Chacon <schacon@> Date: Fri Jun 4 12:37:05 2010 +0200 Merge branch 'change_class' ...
To see a more compact version of the same history, we can use the --oneline option.
$ git log --oneline
8d585ea Merge branch 'fix_readme'
3cbb6aa fixed readme title differently
3ac015d fixed readme title
558151a Merge branch 'change_class'
b7ae93b added from ruby
3467b0a changed the class name
17f4acf first commit
What this is telling us is that this is the history of the development of this project. If the commit messages are descriptive, this can inform us as to what all changes have been applied or have influenced the current state of the snapshot and thus what is in it.
We can also use it to see when the history was branched and merged with the very helpful --graph option. Here is the same command but with the topology graph turned on:
$ git log --oneline --graph
* 8d585ea Merge branch 'fix_readme'
|\
| * 3ac015d fixed readme title
* | 3cbb6aa fixed readme title differently
|/
* 558151a Merge branch 'change_class'
|\
| * 3467b0a changed the class name
* | b7ae93b added from ruby
|/
* 17f4acf first commit
Now we can more clearly see when effort diverged and then was merged back together. This is very nice for seeing what has happened or what changes are applied, but it is also incredibly useful for managing your branches. Let's create a new branch, do some work in it and then switch back and do some work in our master branch, then see how the log command can help us figure out what is happening on each.
First we'll create a new branch to add the Erlang programming language Hello World example - we want to do this in a branch so that we don't muddy up our stable branch with code that may not work for a while so we can cleanly switch in and out of it.
$ git checkout -b erlang Switched to a new branch 'erlang' $ vim erlang_hw.erl $ git add erlang_hw.erl $ git commit -m 'added erlang' [erlang ab5ab4c] added erlang 1 files changed, 5 insertions(+), 0 deletions(-) create mode 100644 erlang_hw.erl
Since we're having fun playing in functional programming languages we get caught up in it and also add a Haskell example program while still in the branch named 'erlang'.
$ vim
$ git add
$ git commit -m 'added haskell'
[erlang 1834130] added haskell
1 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644
Finally, we decide that we want to change the class name of our Ruby program back to the way it was. So, we can go back to the master branch and change that and we decide to just commit it directly in the master branch instead of creating another branch.
$ git checkout master Switched to branch 'master' $ ls README $ vim $ git commit -am 'reverted to old class name' [master 594f90b] reverted to old class name 1 files changed, 2 insertions(+), 2 deletions(-)
So, now say we don't work on the project for a while, we have other things to do. When we come back we want to know what the 'erlang' branch is all about and where we've left off on the master branch. Just by looking at the branch name, we can't know that we made Haskell changes in there, but using git log we easily can. If you give Git a branch name, it will show you just the commits that are "reachable" in the history of that branch, that is the commits that influenced the final snapshot.
$ git log --oneline erlang 1834130 added haskell ab5ab4c added erlang 8d585ea Merge branch 'fix_readme' 3cbb6aa fixed readme title differently 3ac015d fixed readme title 558151a Merge branch 'change_class' b7ae93b added from ruby 3467b0a changed the class name 17f4acf first commit
This way, it's pretty easy to see that we have Haskell code included in the branch (highlighted in the output). What is even cooler is that we can easily tell Git that we only are interested in the commits that are reachable in one branch that are not reachable in another, in other words which commits are unique to a branch in comparison to another.
In this case if we are interested in merging in the 'erlang' branch we want to see what commits are going to effect our snapshot when we do that merge. The way we tell Git that is by putting a ^ in front of the branch that we don't want to see. For instance, if we want to see the commits that are in the 'erlang' branch that are not in the 'master' branch, we can do erlang ^master, or vice versa. Note that the Windows command-line treats ^ as a special character, in which case you'll need to surround ^master in quotes.
$ git log --oneline erlang ^master 1834130 added haskell ab5ab4c added erlang $ git log --oneline master ^erlang 594f90b reverted to old class name
This gives us a nice, simple branch management tool. It allows us to easily see what commits are unique to which branches so we know what we're missing and what we would be merging in if we were to do a merge.
In a nutshell you use git log to list out the commit history or list of changes people have made that have lead to the snapshot at the tip of the branch. This allows you to see how the project in that context got to the state that it is currently in.