In this movie, we're going to talk about how to get more from your commit log. We've already
seen the basics, and we want to see what's in our log for our repository, we can say git log.
That returns a paginated list of everything that's in our git log, and if we hit space it
will just keep going until it gets to the end, and Q will quit of it. So that's the basics
of git log, but there is a lot more we can do with it.
In fact, I really encourage you to go look at the Git help pages for log, because there
are so many options there. You can really fine-tune exactly what you are looking for
and tease out the information about the commits using all of these configuration options, but
I'm going to highlight some of the most important ones.
The first I think is just git log --oneline.
I think it's probably the single most useful option, because it just gives us a oneline
list of what's in our log file, instead of having that long scrolling list, it just compresses
it for us. It still gives us part of the SHA here that we can use to reference each one
those commits if we want to work with it.
We can also use a number of commits to limit the number of commits that it goes backwards,
so, for example, -3 will show us just three commits, -5 will show us five commits. We
can also filter the log by time period.
So for example, git log, and then we can use the since option, since equals and then in
quotes, and we can put a lot of things in here for the time.
For example, 2012-06-20, and it understands that as being 2012 June 20th.
Hit Return, and that's what it gives us, just the entries that are since then.
We can always use after instead of since, those are synonymous.
We can do the same thing, but use until so that's all the commits that are until that
date, and we can use before as well. So before and until both work the same way, and we can
of course combine both of those. We can pass in the time period in other formats as well.
So for example, 2 weeks ago, just as a string, and it's able to figure this out.
Say 3 days ago, so there's everything from 2 weeks ago until 3 days ago, again paginated,
hit Return at the end, and you can even do it just by saying 3.days and 2.weeks, and
it's able to understand that as well.
So any of those formats will all do the same thing. You have a lot of flexibility in the
way that you specify the time period that you want to use.
We can also search by author, so author this is the person making the commits,
I can say I'm looking for everyone with Kevin and the author, so if there were multiple
Kevins, it would show all of them. Instead if I wanted just Kevin Skoglund then of course,
I would write in my name there, and now it shows me just author Kevin Skoglund.
We're the only one making commits at this point, but if we are collaborating with other
people, it's nice to be able to filter out and see, what are the commits that John made?
I want to see John's commits only and see what he was up to last week.
We can also GREP the commit messages. GREP is a global regular expression search, so
we can do git log --grep equals and then whatever regular expression we want to search for we
can put here in quotes. So I'm going to search for temp, and that'll return the two things
that had a message that were about the temp file, and see both of those.
This is really nice if you want to see everything that was committed about a certain topic.
You can see now why having good commit messages is really, really helpful, because it allows
us to be to search for things in the commit message that apply to the particular section
of our code that we might be working on.
We can also specify a range of time periods, let's do just a regular git log, oneline, so
here we are, and let's say we want to see all the commits from this commit, do git log,
and then put that SHA in dot, dot. That's how we indicate a range, all the way up to let's
say this one. So this will show me just those commits, and I'll go ahead and do it as one line
again, so it's really clear what it's doing.
So now it's showing me just those from that commit up to that commit, so that's how we use
a range. We will be using those again a little later on. We can also ask it for information
about what happens to a particular file.
For example, I could say, tell me everything that has happened since the initial commit,
git log from initial commit going forward to, and I could put in a commit or I can
just leave it blank, nothing at the end of the range will say all the way up to the end,
what has happened to the index.html file.
Give me the logs that affect that file, let's try that.
There is one commit that's relevant to it, it's this commit right here, and this is what
changed to that file.
So if you're working on a particular file, and you want to go back in history, and see
what's happened to that file previously, the log will let you do that.
We can find out more details about the commits by using git log -p, this is the patch option,
and it shows us a diff of what actually changed in each one of these.
So here's the additions and here's the subtractions. So we can really see what's different about each one.
That's really nice, especially when we're working with this, find out what happened to
each one of these files, because we can jump back here and right after log we'll put it in
the -p option, and now not only does it tell me what commits apply to this, it actually
shows me the changes as well. So I can do both, all right here, every single change listed
out that happened to the index.html file.
We can do something similar also with git log --stat and --summary, and you can use
those separately or together.
What they'll do is they'll tell you statistics about what changed in each one, so you see
here this, the git ignore file added whole bunch of things.
Here in resources, something was added and something was taken away, and it goes
ahead and gives you a little summary here as well, that's what that summary is.
That's nice if you're not as concerned with the actual details of what happened, you are
just wanting to get an idea of the quantity of things that changed and where.
So as far the log format goes, we saw the most useful one, already which was the oneline,
and git log --oneline is one way to do it, git log format equals oneline is another way to do it.
Now this returns a slightly different thing, because it returns the full SHA instead of
just a partial SHA, so you can compare the two, oneline, oops, I misspelled it. There
it is, so you can see the difference between the two of those.
We can also specify other formats though which is why it's nice to know about the format
version, because in addition to saying oneline, we can also use short or we can use medium
which is the default one that we already seeing, we can see full, that gives us a little more
information, like the commit author, and there's fuller which gives us even more information.
There is email, which generates it in a format useful for mailing an email, and then there's raw.
It's really showing us the raw information that's stored in Git.
The last one I'm going to leave you with is one that I think is pretty cool, git log --graph.
So this shows us a graph of each one of our commits.
Now right now our graph is pretty straightforward and linear, but if we start having branches,
and we start branching thing off and then merging things back in, then this really shows
us those branches are merged, so we'll come back and try that a little later.
A nice combination of them is git log --oneline --graph --all --decorate, so let's put all
those together, and you'll see that it gives us a nice compact list. It'll show all the
branches that take place and even tells us right now that this is where the HEAD is pointing,
and this is the tip of the master branch.
So this is a nice combination of options that's worth remembering. Please experiment, find
more, dig through the log files and find formats that are useful for you in the way that you
like to work.