Git Log | A Comprehensive Guide To Using Git Log Command

One of the main purposes of using Git, the version control platform, is to be able to track the changes made in a project. While the whole history of the commits and changes made is available in Git, it is the Git log command that helps us see the project history in the repository and navigate it. In addition to being able to access the commit history, the Git log command also allows users to list, filter, and search a Git project history for certain modifications. Note that the Git log functions only on the committed history, whereas it is the Git status command allows us to check the working directory and the staging area.

What Is Git Log?

The command git log shows a single repository's commit history, and the tool accepts options applicable to the git diff command to display the changes made in each commit. It also takes options applicable to the git rev-list command to customize what is presented and how.

Git Log Syntax

The basic command to access the log for a project is git log. But the proper syntax used to access specific history is as follows:

git log [<options>] [<revision-range>] [[--] <path>…]

Here,

<options>: This git log command gives the option to display Git diffs along with the commit history. The options inside angular brackets contain the details of the additional options that are relevant to display the changes made in each commit. It also leads to the display settings that are applicable to the git rev-list tool to version control what is presented and how.
<revision-range>: This indicates the range of commits to display. This can be a single commit, a Git branch name, a tag name, or a range of commits specified by two commit IDs separated by two dots.
[[--] <path>…]: This refers to the list of files or directories to limit the output within.

Description Of Git Log Command

As mentioned before, the git log command can be used to access the history in a repository. In addition, it also helps perform the following tasks-

Filter commits according to specific requirements.
Search for specific changes made in the past.
Prepare a list of commits made.
Present log in a user-defined format.

These are a few ways we can customize the git log command. It is important to note that the default log output format to show these commits in the repository is in reverse chronological order, with the most recent ones at the top of the list.

As per the default format, each single commit object level in the single repository is represented in the output of the Git log by its SHA, author, date, and commit message.

Options In The Git Log Command

As mentioned above, there are many common options that go along with the git log command and present a more detailed explanation in reference to the commit history. Some of these are as follows:

--oneline: This option produces an overview of the respective Git project, and it presents a meaningful history in default mode. It displays each commit on a single line.
-n: This option limits the number of commits displayed in the respective log history. For example, git log -n 2 displays only the two most recent commits

--author=: This option filters or searches the version control history and commits to look for commits based on the author. For example, in the image below, the option searches for commits by author name.

--since=: This option filters the commits by date. For example, git log --since="7 weeks ago" displays only the commits made in the last seven weeks
--clear-decorations: This option relaxes the default decoration and clears all previous --decorate-refs or --decorate-refs-exclude settings when used with git log.
--perl-regexp: A Perl-compatible regular expression can be used to filter commits with the --perl-regexp option in the git log. This option enables us to search for commits that match a specified single pattern in the commit message or other areas of the commit information using regular expressions that are compatible with Perl.

These are just a few of the many options available along with the git log command and do not span the complete list of options.

How To Navigate Git Log?

Git uses the less terminal window pager to browse the Git log output. The following commands can be used to browse the output of the Git log:

To scroll down by one line, we can either use the 'j' or the '↓' key.
The 'k' or '↑' key can be used to scroll up one line.
Use the spacebar or the Page Down button to navigate down one page.
The key 'b' or the Page Up button helps scroll up one page.
We shall use the 'q' key to terminate the log.
The flags are used to modify the data that the Git log presents in addition to scrolling through the output of the Git log.

How To Exit The Git Log?

Terminating the Git log command is quite simple. As mentioned above, this can be done using the 'q' key on the keyboard, which ends the log. The steps to exit the Git log command are:

Step1: We will redirect to the local directory by writing the following command:
$ cd "C:\Git\Repo1"
Step2: This step involves checking the git log by using the following command:
$ git log –oneline
Step 3: By pressing the q key on the keyboard, we can exit the git log without duplicating the commit default history.

Commit Formatting In Git Log

Git log offers a number of formatting options in the special line-based format for the commit meaningful history branches. Using the formatting options, you can modify the Git log command's output just to show the data you require. Discussed in this section are some of the most common formatting options for Git Log.

Git Log Oneline

The --oneline option is used with the Git log command to display each commit on a single line. This is especially useful for an overview of the Git project history. Note that when we use the --oneline option, the commits are printed in a specific pattern/ log output format, i.e., the commit SHA's initial 7 characters followed by the commit message.

Command Example: git log –oneline

Decorating In Git Log

Decorating in Git log refers to the display of extra line details about the history of commits, like the names of the branches and the tags that identify each commit. The git log command's --decorate option is used to show any references (such as branches, tags, etc.) that point to each commit.

In other words, the --decorate config option can give us a more thorough understanding of the logical structure of our single repository when used in conjunction with other config options like --oneline, --graph, and --simplify-by-decoration.

Example of --decorate option:
git log --oneline –decorate
This command displays (in a single line) the commit message, the first seven characters of the SHA, as well as the names of the branches and tags that each commit points to. We must use the --decorate option to add the branch and tag names to the output.
There is a --simplify-by-decoration option that picks only the commits that are referenced to, by a certain branch or tag in addition to the --decorate option.
This option can be helpful in condensing the commit history lines when working with large repositories.

The --abbrev-commit Option

The --abbrev-commit option in the Git log is used to show only a partial prefix of the full 40-byte hexadecimal commit object name. This option is negated by the --oneline option, which shows the commit SHA's initial 7-character encoding followed by the commit message. Additionally, this option is overridden by the log.abbrevCommit variable.

The --no-abbrev-commit Option

The --no-abbrev-commit option in Git log is used to show the full 40-byte hexadecimal commit object name instead of a partial shortest prefix. This option overrides the --abbrev-commit option and the log.abbrevCommit variable.

The --parents Option

Git log has a command-line option called --parents that can be used to show the commit parent list of each output for merge commits.

For example:

git log --pretty=format:"%h %s" --parents

This command will display the abbreviated commit hash (%h) and subject (%s) of each commit, followed by the abbreviated parent hash of each parent list directory.

The --show-linear-break[=<barrier>] Option

It can be challenging to recognize that two successive or consecutive commits do not belong to a linear branch when the --graph is not used because all default history line branches are flattened.

In such a situation, the --show-linear-break[=<barrier>] option places a barrier between them.
So, if <barrier> is provided, that string will be displayed as opposed to the default one.

The --date=iso Option

The --date=iso option in Git log is used to format the commit date in a manner similar to ISO 8601-like format.

This option displays the commit's timestamp in the format YYYY-MM-DDT.HH:MM:SS±hh:mm, which denotes the date and time separation.
In addition, the hh:mm segment denotes the time zone offset from UTC.
It is necessary to have a day and time zone because there are many people who work together on a single project.
Note that the difference between this option and the strict ISO 8601 format is the absence of first the delimiter (T) which is replaced by a space between time and time zone, and second the colons between the hours and minutes.

Pretty Formatting In Git Log

In Git, the --pretty option is used with the Git log command to format the commit default mode history output.

The --pretty option allows you to specify a custom output format for the commit history lines.
The log output format can be one of oneline, short, medium, full, fuller, email, -raw format output:<string>. Note that it defaults to medium when the =<format> part is omitted.

Let's look at some command examples of pretty formatting in the Git log.

git log --pretty=oneline
This command displays each current commit on a single line during the code movement, with the first seven literal characters of the SHA and the commit message sequences of bytes.

git log --pretty=format:"%h - %an, %ar : %s"
This command displays each commit in a custom format, with the abbreviated commit hash, author name, author date relative to now, and commit message
%(trailers[:options])
In Git, the %(trailers[:options]) placeholder in the 'pretty formats' of Git log allows us to display commit trailers in a customizable way. Commit trailers are key-value pairs that provide additional information about a commit, such as the "Signed-off-by" line or "Reviewed-by" line.
Example:
git log --pretty=format:"%h %s%n%(trailers:key=Reviewed-by,valueonly)"
In the example above, %h represents the abbreviated commit hash, and %s represents the commit subject. The %n is used to insert a new line. The %(trailers:key=Reviewed-by,valueonly) option is used to display only the values of the "Reviewed-by" trailers.
A trailer block is a section within a commit message that contains one or more commit trailers. Each trailer block consists of a key-value pair separated by a colon.
For example:
Reviewed-by: John Doe
Signed-off-by: Jane Smith

Diff Formatting In Git Log

The Diff option (i.e., --diff) in the Git log is used to view the differences between commits.

The diff command output for each commit is shown, along with the changes made to the file mode in that commit.
We can use the -p option for the Git log to show the diff for each commit in the log. This option displays the whole diff with respect to every commit that is recorded in the log.
Here is an illustration of how to use the -p option of the Git log command to display the commit history and diff:
- git log -p
- This command line argument shows the complete diff for each commit along with the commit history.

The format of diff in the Git log can be modified in many different ways. Some of these are as follows:

In the diff output, the --color-words option indicates the words that have changed.
The --word-diff-regex option allows us to customize the regular expression that is used to match words.
- For instance, the command below can be used to show the diff for a certain file type in a unified format.
- git log --diff-filter=M --follow --unified=3 -- path/to/file
- This command in the example above displays the commit history for the list of path/to/file, along with a uniformly formatted diff for each commit and three context lines or separate lines.
The --follow option follows the file across renames, and the --diff-filter=M option only displays commits that modify the file.
The --no-diff-merges option in the Git log can be used to prevent merge commits from showing diffs in the log output. In other words, it disables the output of diffs for merge commits.
- Example:
  git log --no-merges --no-diff-merges
- This command line argument will show the log output without the display of merge commits and without diffs for merge commits.
The --remerge-diff option helps create a temporary tree object by re-merging two-parent merge commits. This temporary tree object may contain files with conflict markers, and it shows diff between the actual merge commit and the temporary tree.
- Example:
  git log --remerge-diff
The -O<orderfile> option in Git diff can be used to output the patch in the order specified in the <orderfile>. This means this option ignores the blank lines, so they are used as the separators for readability.
- Example:
  git diff -Oorder.txt
- This command will output the patch in the order specified in the order.txt file, and the output order is determined by the order of glob patterns in <orderfile>.
The --abbrev[=<n>] is an option to version control the length of the SHA-1 object names in the output of various Git commands, including git diff, instead of showing diff-tree file header lines.
- By default mode, Git abbreviates SHA-1 object names to 7 characters in the output of git diff.
- Example:
  $ git diff --abbrev=10
- This command will show the diff output with the first 10 alphanumeric characters of the SHA-1 object names.
The -S<string> option in Gitt diff is used to search for differences that introduce or remove an instance of <string> or when looking for an exact block of code.
- Example:
  $ git diff -S"hello"
- This command will show the diff output that introduces or removes the string "hello" in the codebase.
The --full-index option in Git diff is used to display the full SHA-1 blob object names in the patch output, regardless of the --abbrev option.
The --stat[=<width>[,<name-width>[,<count>]]] option: We employ this option to generate a summary of the changes made to the files being compared. The total number of lines edited, as well as the number of lines added to and removed from each file, are displayed in the git diff option's summary.
- By combining the --stat option with the optional <width> parameter, we can determine the output's maximum width.
- If <width> is not specified, the maximum width defaults to the terminal width, or 80 columns if not connected to a terminal.
The --porcelain option in Git diff is used to generate machine-readable output that is suitable for script consumption. The output generated by --porcelain is similar to the output generated by the --short option but with a more strict format that is easier to parse by scripts.
- The --porcelain option is useful when you need to process the output of Git diff programmatically.
- Example:
  git diff --porcelain
- The diff output will be displayed with this command in a machine-readable format.
The --find-copies-harder option: This option of the Git diff command is used to find copies of files that have been altered in the same changeset.
- The -C option, by default mode for performance reasons, only locates copies when the original file of the copy was altered during the same changeset.
- However, with --find-copies-harder, Git diff will search for copies even if the original file was not modified in the same changeset.
- Example:
  git diff --find-copies-harder
  This command will show the diff output with copies of files that were modified in different changesets.
The -z option: In git diff, the -z option is used to separate filenames and commits with NULs and other metadata with null bytes instead of newlines. This option is useful when dealing with filenames that contain spaces or other special characters, as it ensures that scripts correctly parse the filenames.
- Example:
  git diff -z --raw
- This command will show the diff output with filenames and other metadata separated by null bytes.

The --ignore-submodules[=<when>] option: This option is used to exclude the changes in submodules when formatting the output of the diff generation Git log command.
- Example:
  git log --ignore-submodules=dirty
- This command will show the commit history, ignoring changes in submodules that have changes in the working tree.

The --diff-merges=separate option: To display the complete diff of merge commits with regard to each parent list commit individually, we use the --diff-merges=separate option in Git log and separate log entry, and the diff is generated for each parent.
- By default, Git shows the pairwise diff between the merge commit and each parent list commit.
- This can be confusing when trying to understand the changes introduced by the merge.

Combined diff Format

In Git, the changes made by a merge commit are displayed using the combined diff format.

It demonstrates the variations between the merge commit and each of its parents, as well as the variations within the parents.
It is followed by a two-line header or tree header line.
Any diff-generating command that shows a merging can accept the -c or --cc argument to produce a combined diff. This is the default format for such commands when showing a merge.
For example, we may use the command below to utilize Git log to display the merged diff for a merge commit:
git log -p -c
This command shows the combined diff for the modifications brought about by the merge, along with the commit's message, author, and date.

Here is an illustration of a command to create a mixed-diff format for a particular file mode:

git log -p -c -- path/to/file

The aggregate diff format for all the commits that affect the specified file systems is displayed by this command.

The output code block of the command git log -p -c will resemble this:

commit 1234567890abcdef1234567890abcdef12345678
Author: John Doe <johndoe@example.com>
Date: Mon Jun 21 12:34:56 2023 -0700
Merge branch 'feature-branch'
Conflicts:
path/to/file
diff --cc path/to/file
index 1234567..abcdefg
--- a/path/to/file
+++ b/path/to/file
@@@ -1,2 -1,2 +1,3 @@@
line 1
line 2
++line 3

This output displays information about the merging commit, a list of the files that conflicted during the merge (if any), and then the combined diff format for the merge commit. In the combined diff format, both the changes made to the file systems in the merging commit and the modifications made in the parent list commits are displayed.

Generating Patch Text With -p In Git Log

The Git format-patch tool can be used to produce a patch text with the -p option in Git log. For each commit in the provided range, this command creates a patch file. The -p option allows us to specify how many leading slashes should be dropped from the file names in the patch.

Example:

git format-patch -p1 HEAD~3..HEAD

With this command, a patch file is created for the most recent three commits. The first slash in the file mode names in the patch is removed when using the -p1 option. The range of commits for which patches should be created is specified by the HEAD~3..HEAD.

Git Log Graph History

To visualize the commit-graph history in Git, we can use the Git log command with the --graph flag option. This option displays the text-based graphical depiction of the commit history on the left side of the output.

Here's an example of using git log with the --graph option:

git log --graph

This command or --graph option will show the branch and merge points together with the commit history graph. However, the output occasionally tends to be verbose and challenging to read. Other options like --oneline, --decorate, and --all can be used to make the output more legible and concise.

Here's an illustration of how to use the --graph option with --oneline, --decorate, and --all options in Git log:

git log --all --decorate --online --graph

This --graph option will show a condensed commit history graph with branch and tag names, all branches, and one-line commit messages.

We can use other Git log parameters to tailor the output further. For instance, we can provide a specific output format with the --pretty option. Here is an illustration of how to use the --graph, --pretty, and --all options with git log:

git log --graph --pretty=format:'%C(yellow)%h%Creset %s %Cgreen(%cr)%Creset' --all

This --graph option will show a custom-formatted commit history graph that includes the commit hash, commit message, and commit relative time.

The Shortlog

This is a modified version of the Git log command. The Git shortlog groups each commit by author and shows the first line of each commit message to provide a summary of the commit history.

The shortlog is useful for making release announcements or rapidly identifying who has been working on what.
For example, to obtain a summary of the commit history for the active branch, use the following command:

git shortlog

The first line of each commit message and the author's name will be displayed together with a list of all commits, categorized by author.

A number of variables can be used to personalize the git shortlog's output. For instance, we can display the number of commits per author while hiding the commit messages using the -s option. For example:

git shortlog -s

The author with the fewest commits will be listed first if we use the -n option to reverse the order of the output's commit count sorting.
When comparing commit messages, we can use the -w option to eliminate whitespace and the -e option to display the Author email addresses.

Git Log: Filtering The Commit History

While Git log gives one access to the commit history of a project, you will need to apply a series of filters to reach the information you need. Users can choose a subset of commits in Git's commit history based on author, date, or message in bytes by filtering the commit history.

Example of filtering commit history using Git Log options:

Filtering by author: The --author=author> option allows us to show only the commit's simplified history made by a certain author.
Filtering by date: The --since=<date> and --until=<date> options allow us only to show commits that were made between two ranges of dates in particular.

Filtering by message: To display only the commits whose message contains a certain keyword, we will use the --grep=<keyword> option.

Commit Ordering In Git Log

The order in which the commits are shown is referred to as the commit ordering in the Git log. By default, the most recent commits appear first, i.e., the Git log lists the commits made in a repository in reverse chronological order.

The commits can alternatively be sorted by timestamp rather than by their usual commit history.
This can be achieved using the --date-order option with the Git log command instead of using the author-date, which is the date that the contribution was authored.
The --date-order option organizes the commits according to their commit date, which is the date that the commit was made.
For example:
git log --date-order
Another approach to use the timestamp for sorting the commits is the --reverse option with the Git log command.
This option changes the output's default order so that the first commit is listed first, and the remainder of the commit history is listed after it in ascending order.
For example:
git log --reverse

The --topo-order: When viewing a merging commit, the --topo-order option in the Git log is used to restrict the log's display of commits to just the first parent list commit. This option offers a greater overview of the string of commits that took place on a particular branch. This can be helpful when analyzing the evolution of a certain branch, and it avoids showing commits on multiple lines of history intermixed.

Commit Limiting In Git Log

Git log's concept of commit limiting refers to the practice of only showing a portion of the repository's available commits. This can be particularly useful when working with big repositories or attempting to concentrate on a particular segment of the commit history.

For Example:

--first-parent option

The --first-parent option in the Git log is used to restrict the log's display of commits to just the first parent commit due to its strict policy, when viewing a merging commit.

This option offers a greater overview of the string of commits that took place on a particular topic branch, which can be helpful when analyzing the evolution of a certain branch.
This option allows you to ignore the specific commits added to your history by a topic branch merge, which can help you get a better overall picture of how that branch has evolved from time to time.

Example of how to limit commit.

Limiting the number of commits: When displaying the number of commits, we can use the -n option. For example, to show only the last 7 commits: git log -7.
Limiting the commits by date: The --since and --until options allow us only to show commits that were made between two specific dates. For instance, to display commits from the previous week: git log --since="1 week ago"
Limiting the commits by message: To display only the commits whose message contains a particular term or pattern, we shall use the --grep=pattern> option.

In general, limiting the number of commits displayed in the Git log gives users a means to concentrate on the most relevant commits and gain an understanding of the git project's development history.

Git Log & History Simplification

In the Git log, the term history simplification refers to the act of removing extraneous or redundant information from the commit history. This technique offers a concise and straightforward picture of the commit history.

It might hence be helpful in handling complicated branching and merging circumstances.
Selecting the commits and figuring out how to accomplish it are the two main components of history simplification because there are many different approaches.

Some examples of different approaches are given below:

--simplify-merges: This option eliminates certain unnecessary merged branches from the output.
--show-pulls: This only displays commits with pull requests.
--full-history: It shows all of the repository's history, including all branches and tags.
--dense: Only commits with a direct parent-child relationship are displayed.
--sparse: It only displays commits that do not directly involve a parent and a child directory.
--ancestry-path[=<commit>]: It only displays commits that are in the specified commit's ancestry path.
--full-history without parent rewriting: It presents the repository's whole history without parent rewriting.

Git Log Configuration Commands

The term Git log configuration describes the many parameters and commands that can be used to alter the Git log command's output.

Some examples are:

format.pretty: It uses a custom format string to specify the output format for the log.
log.abbrevCommit: The commit SHA-1 checksum is condensed to a smaller, more manageable size by using this option.
log.date: The default date-time mode format to be used in the output is specified by log.date.
log.decorate: It adds more details to the report, like the branch and tag names that identify each commit.
log.initialDecorationSet: The initial commit set of decorations to be used in the output is specified by log.initialDecorationSet.
log.excludeDecoration: It omits particular decorations from the output.
log.graphColors: It specifies the list of colors to be used in the output of the graph.
notes.<name>.mergeStrategy: It defines the default notes merge strategy to be used.
notes.displayRef: Choosing this option specifies the reference to utilize when displaying notes.
notes.rewrite.<command>: With this option, the command to use when rewriting notes is specified.

With the help of this config option, users can alter the Git log's output and learn more about the background and development of the Git project.

notes.rewriteRef

The notes.rewriteRef is a config option in Git that is used to specify the ref whose default commit notes should be copied when copying notes during a rewrite.

This option must be set to enable note rewriting and does not have a default value.
It can be overridden with the GIT_NOTES_REWRITE_REF environment variable.
The notes.mergeStrategy configuration option can be used to select the default strategy for merging notes.

log.showRoot

The log.showRoot config files in Git log determine whether or not to show the root commit in the log output. And if it shows the initial commit, it will be shown as a creation event.

Example:
git config --global log.showRoot false

This command will set the log.showRoot config files to false globally, which means it will apply to all repositories.

log.graphColors

The log.graphColors configuration in git log is used to customize the list of colors of the graph lines in the output of the git log --graph command.

This configuration allows us to specify a list of colors that Git will use to color lines of code the graph lines based on the branch or tag they represent.

Conclusion

Git log is a strong command that can give us access to the past of our Git repository. It is a priceless resource for developers since it can provide a complete history of a repository packed with commit messages, authors, and timestamps.

To format the output, we can select the commits that are included in the output and condense the commit history. The Git log can be customized using a number of parameters and commands. Users can also monitor changes made to their repository and identify who made what changes in Git using the Git log tool.

FAQs

Q. How can I view the commit history for a specific file?

Using the git log command and the --follow option after the file path will allow us to see the Git commit history for a particular file mode. This option will display the file's commit history, which includes any alterations made to the file mode during a rename or move.

git log --follow <file-path>

Q. How can I see the author and date information for each commit?

To see the author and date information for each commit in the Git repository, we can use the git log command with the --pretty option and specify the desired format.

git log --pretty=format:"%an - %ad - %s"

Q. What is the git log used for?

The Git log is a command used to view the history of committed changes within a Git repository. It allows users to list and filter the Git project history, search for specific changes, and find a particular version of a Git project. The command displays committed snapshots and operates on the committed history.

Q. Is there any git login command?

There is no Git login command since we don't have to input a username and password each time we interact with Git on our computer. We can substitute by using a credential assistant like Git Credential Manager or caching our credentials in Git.

Q. What is git log one line?

The Git log one line is an option of the Git log command that displays the output as one commit per line. It displays the output in brief, including the first seven characters of the commit SHA and the commit message. This option is useful when you want to quickly view the commit history in a concise format. The output format of this command is the commit SHA's initial 7 characters followed by the commit message.

Q. How can I limit the number of commits displayed in the log?

We can use the --max-count=number> option to restrict the number of commits that are displayed in the log. For instance: --max-count=number> in git log.

Q. How can I search the commit log message for a specific keyword or message?

To search the commit log message for a specific keyword or message in the Git log, we can use the –grep option. The syntax for this will be-

git log --grep=<keyword>.

The <keyword> must be replaced by a specific message that we want to search for.

You might also be interested in reading the following:

Shivani Goyal

Manager, Content

I am an economics graduate using my qualifications and life skills to observe & absorb what life has to offer. A strong believer in 'Don't die before you are dead' philosophy, at Unstop I am producing content that resonates and enables you to be #Unstoppable. When I don't have to be presentable for the job, I'd be elbow deep in paint/ pencil residue, immersed in a good read or socializing in the flesh.