Resources     Blog  

  1. Home
  2. Git Tutorials
  3. How To Inspect a Git Repository

How To Inspect a Git Repository

You can inspect a Git repository by using the git status command. This command allows you to see which changes have been staged, which haven’t, and which files aren’t being tracked by Git.

You should try and remember that status output does not show you any information regarding the committed project history. For this, you need to use the git log command.

Before I jump into the git status command and how to use it to inspect a Git repository let’s take a look at some related Git commands that may be useful for this portion.

  • git tag: Tags are references that point to specific points in Git history. git tag is generally used to capture a point in history that is used for a marked version release.
  • git blame: The high-level function of git blame is the display of author metadata attached to specific committed lines in a file. This is used to explore the history of specific code and answer questions about what, how, and why the code was added to a repository.
  • git log: The git log command displays committed snapshots. It lets you list the project history, filter it, and search for specific changes. This is used often when you are saving changes in Git.

Git Status Command Usage

git status

As mentioned above, this lists which files are staged, unstaged, and untracked.

While Git can be complicated at first, especially for a beginner, the git status command is a pretty straightforward Git command. Basically, it shows what has been going on with git add and git commit.

Status messages will also show relevant instructions for staging and/or unstaging files. Below is a sample output showing the three main categories of a git status call:

# On branch master
# Changes to be committed:
# (use “git reset HEAD <file>…” to unstage)
#
#modified: hello.py
#
# Changes not staged for commit:
# (use “git add <file>…” to update what will be committed)
# (use “git checkout — <file>…” to discard changes in working directory)
#
#modified: main.py
#
# Untracked files:
# (use “git add <file>…” to include in what will be committed)
#
#hello.pyc

Ignoring Files When Needed

More often than not untracked files in Git fall into two categories. They are either files that have just been added to the project but not yet committed, or they are compiled binaries like .pyc, .obj, .exe, and so on.

While it is very beneficial to include the former in the git status output, the latter can make it hard to see what’s actually going on in your repository. You don’t want that, you want to be able to see clean and clear what exactly is going on.

To deal with this issue Git, allows you to ignore files completely by placing paths in a special file called .gitignore. Any files that you would like to ignore should be included on a separate line, and the * symbol can be used as a wildcard.

For example, adding the following to a .gitignore file in your project root will prevent compiled Python modules from appearing in git status:

*.pyc

For example, you always want to inspect the overall state of your repository before committing changes so that you don’t accidentally commit something you don’t mean to. This displays the repository status before and after staging and committing a snapshot:

# Edit hello.py
git status
# hello.py is listed under “Changes not staged for commit”
git add hello.py
git status
# hello.py is listed under “Changes to be committed”
git commit
git status
# nothing to commit (working directory clean)

Using Git Log Command

The git log command displays committed snapshots. The command will allow you to list the project history, filter it, and search for specific changes.

So while git status allows you to inspect the working directory and the staging area, git log only operates on the committed history.

There are many ways to customize log output. Here are some of the most common configurations of git log:

git log

This displays the entire commit history using the default formatting. If the output takes up more than one screen, you can use Space to scroll and q to exit.

git log -n <limit>

Limit the number of commits by <limit>. For example, git log -n 4 will display only 4 commits.

git log –oneline

Condense each commit to a single line. This is useful for getting a high-level overview of the project history.

git log –stat

Along with the ordinary git log information, this will include which files were altered and the relative number of lines that were added or deleted from each of them.

More Git Log Configurations

git log -p

This shows the full difference of each commit, which is the most detailed view you can have of your project history.

git log –author=”<pattern>”

This allows you to search for commits by a particular author. The <pattern> argument can be a plain string or a regular expression.

git log –grep=”<pattern>”

This allows you to search for commits with a commit message that matches <pattern>, which can be a plain string or a regular expression.

git log <since>..<until>

This will only show commits that occur between <since> and <until>. Both arguments can be either a commit ID, a branch name, HEAD, or any other kind of revision reference.

git log <file>

This will only display commits that include the specified file. This is an easy way to see the history of a particular file.

git log –graph –decorate –oneline

These are a few more useful options you may want to consider. The –graph flag that will draw a text-based graph of the commits on the left-hand side of the commit messages. –decorate adds the names of branches or tags of the commits that are shown. –oneline shows the commit information on a single line making it easier to browse through commits at-a-glance.

Final Thoughts

I hope this has shown you how to properly inspect a Git repository. By using the git status and git log commands and combining them with different configurations, you can successfully navigate and inspect any Git repository. Therefore, improving your efficiency when working on projects.

Learn as much as you can about Git and it will make using it easier in the long run.

Author: Jeremy Holcombe

Growing up in Hawaii, Jeremy started his freelance writing career doing resumes, business plans, article writing, and everything in between. He now specializes in online marketing and content writing and is part of the Content Marketing Team at GreenGeeks.

Was this article helpful?

Related Articles

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.