Viewing Git History and Changes: git log and git diff Tutorial

Viewing History and Changes

One of Git's most powerful capabilities is the ability to look back through your project's history and understand exactly what changed, when it changed, and who changed it. Whether you are tracking down when a bug was introduced, reviewing a teammate's contribution, or simply trying to remember what you worked on last week, Git provides a complete, transparent view of every change your project has ever seen.

In this guide, you will learn how to explore commit history and analyze file changes using essential Git commands. These tools turn Git from a simple save system into a powerful investigation tool that helps you understand your code at a deeper level. If you are not familiar with how commits work, take a moment to revisit Git core concepts before continuing.

Why Viewing History Matters

Every commit in Git is more than just a saved version of your project. It is a permanent record that captures the state of your code, along with metadata that tells you who made the change, when they made it, and why. Being able to navigate this history effectively transforms how you approach debugging, collaboration, and project management.

• Track project evolution: See how your codebase grew from a simple script to a complete application, understanding the decisions made along the way.
• Identify bug origins: Pinpoint exactly which commit introduced a problem, making fixes faster and more targeted.
• Understand team contributions: Review what your colleagues have been working on and why certain design decisions were made.
• Restore with confidence: When something breaks, knowing how to view history means you can confidently revert to a known good state.

Viewing Commit History

The git log command is your window into your project's history. It displays a list of commits in reverse chronological order, showing the most recent commits first. Each entry typically includes the commit's unique identifier (a 40-character SHA-1 hash), the author, the date, and the commit message that explains what changed and why.

git log

This output is comprehensive but can be overwhelming for larger projects. To make it more readable, you can use a compact format that shows each commit on a single line. This is often the preferred way to quickly scan through history.

git log --oneline

The --oneline flag shows the abbreviated commit hash alongside the commit message, giving you a clean, scannable list that makes it easy to identify commits of interest. From there, you can dive deeper into any commit that catches your attention.

Limiting and Filtering History

Real-world projects can have hundreds or thousands of commits. Scrolling through all of them is rarely practical. Git provides a variety of filters that let you narrow down the history to exactly what you need, saving time and mental energy.

# Show only the last 5 commits
git log -n 5

# Show commits by a specific author
git log --author="Sarah"

# Show commits made after a specific date
git log --since="2024-01-01"

# Show commits containing a specific keyword in the message
git log --grep="authentication"

These filters help you focus on relevant changes without wading through unrelated commits. Combining filters gives you even more precision—for example, git log --author="Sarah" --since="last week" shows only Sarah's commits from the past seven days.

Understanding git diff

While git log tells you what happened in terms of commit messages, git diff shows you the actual content changes. It reveals exactly which lines were added, modified, or removed between any two points in your project. This is where Git moves from showing you metadata to showing you substance.

You can use diff in several ways depending on what you want to compare. Each variation serves a different purpose in your daily workflow.

Compare Working Directory with Staging Area

git diff

This shows changes that exist in your working directory but have not yet been staged. Use this to review what you have changed before deciding which files to stage. It is your last chance to double-check your work before it becomes part of history.

Compare Staged Changes

git diff --staged

This shows changes that have been staged with git add but not yet committed. Use this to review exactly what you are about to commit, ensuring that you are not accidentally including debugging code, temporary files, or changes that belong in a separate commit.

Compare Between Commits

git diff abc1234 def5678

This allows you to see differences between any two commits in your history. Replace abc1234 and def5678 with actual commit hashes. This is particularly useful for understanding what changed between two points in time, such as comparing a buggy version to a working version to identify the problematic changes.

Reading Diff Output

The output of git diff may look intimidating at first, but it follows a consistent and readable pattern once you understand it. Git uses color coding by default to make changes easier to spot—green for additions, red for deletions.

• + (green): Indicates lines that were added in the newer version
• - (red): Indicates lines that were removed from the older version
• @@ markers: Show line numbers and context boundaries, helping you locate where changes occurred in the file
• Unchanged lines: Provided as context so you can see the changes in their proper surroundings

Once you become comfortable reading diff output, you will be able to quickly assess the impact of any change just by glancing at the output.

Viewing Changes in a Specific File

Large projects contain many files. When you only care about changes in one area, you can limit diff output to a specific file. This keeps your focus narrow and prevents you from being distracted by unrelated changes.

git diff src/components/Header.js

This works with any diff variation—you can compare staged changes, unstaged changes, or specific commits for a single file. It is an essential technique when working on large codebases.

Comparing Branches

One of the most common diff use cases is comparing branches. Before merging a feature branch into your main branch, you want to understand exactly what changes you are about to introduce. The branch comparison gives you that visibility.

git diff main feature/new-login

This command shows all changes that exist in feature/new-login but not in main. It gives you a complete picture of what you are about to merge, allowing you to catch potential issues before they become part of your stable branch. To understand branches and how they work together, explore Git branching fundamentals.

Using git show for Detailed View

Sometimes you want to inspect a single commit in full detail—its message, author, date, and the exact changes it introduced. The git show command does exactly that, combining the best of git log and git diff for a single commit.

git show commit-id

You can also use HEAD to refer to the most recent commit, HEAD~1 for the commit before that, and so on. This makes it easy to inspect recent work without looking up specific commit hashes. git show HEAD~2 displays the third-most-recent commit, for example.

Practical Workflow Example

Here is how you might use history and diff commands in a realistic development workflow. This sequence demonstrates the natural rhythm of checking your work before and after commits.

# Check recent commits to understand context
git log --oneline -n 5

# See what you have changed but not staged
git diff

# Stage the files you want to commit
git add src/feature.js

# Verify what you are about to commit
git diff --staged

# Commit with a clear message
git commit -m "Add validation to user input"

# Review what you just committed
git show HEAD

# If working on a branch, see how it differs from main
git diff main

This workflow ensures that you stay aware of your changes at every stage, catching mistakes early and maintaining a clean, meaningful commit history.

Common Mistakes to Avoid

Even experienced developers occasionally slip up when working with history and diffs. Being aware of these common pitfalls helps you avoid them entirely.

• Not reviewing changes before committing: Skipping git diff before committing increases the chance of accidentally committing debugging code, temporary changes, or sensitive information like API keys.
• Confusing staged and unstaged differences: Remember that git diff shows unstaged changes, while git diff --staged shows staged changes. Using the wrong one can give you a false sense of what you are about to commit.
• Using incomplete commit IDs: When comparing commits, you only need enough characters to uniquely identify the commit. Git accepts partial hashes as long as they are unambiguous.
• Ignoring commit messages when analyzing history: Commit messages exist to explain why changes were made. When investigating history, reading these messages often provides critical context that diff output alone cannot convey.
• Forgetting that history is local until pushed: Your local history exists only on your machine until you push it. If you make mistakes, you have flexibility to fix them. Once pushed, be more careful.

If mistakes do happen, Git provides reliable recovery paths. Learn how to safely undo changes in undoing changes in Git.

Frequently Asked Questions

1. What is the difference between git log and git diff?
   git log shows commit history—the metadata about when commits happened and what messages they contain. git diff shows the actual content changes—which lines were added, removed, or modified between two versions. Think of git log as the table of contents and git diff as the detailed chapter content.
2. Can I view changes before committing?
   Absolutely. In fact, reviewing changes before committing is considered a best practice. Use git diff to see unstaged changes and git diff --staged to see what you are about to commit. This double-check catches many common mistakes.
3. How do I find a specific commit when I only remember part of the message?
   Use git log --grep="partial message" to search commit messages. For searching through the actual code changes, consider using git log -S"text" which finds commits that added or removed the specified string in the code itself.
4. Is git diff hard to understand?
   It can be intimidating at first, but the pattern is consistent. Green lines with + are additions, red lines with - are deletions. The context lines around them help you understand where the changes fit. After a few uses, reading diffs becomes second nature.
5. What should I learn next after mastering history and diffs?
   With a solid understanding of viewing history and changes, you are ready to explore how to manage parallel development. Dive into Git branching fundamentals to learn how branches enable feature development, experimentation, and team collaboration without interfering with stable code.

Conclusion

Viewing history and understanding changes are foundational skills that separate casual Git users from developers who truly leverage Git's power. The ability to navigate through your project's past, pinpoint exactly when and why changes occurred, and inspect the details of those changes transforms how you debug, collaborate, and maintain your code.

By regularly using git log to understand your project's trajectory and git diff to verify your changes, you build confidence in your workflow. You stop wondering what changed and start knowing exactly what changed. Continue building your Git skills by exploring Git basic workflow to see how these history tools integrate into your daily development routine, and then move on to Git branching fundamentals to master parallel development.