Commits, Identity, History, and Comparison

A commit is a permanent recorded version in the local repository. It takes the current contents of the staging area, saves them in project history, attaches author information and a message, and assigns the commit a unique identifier.

Committing is not the same as editing, staging, or pushing. It is the transition from a reviewed staging area into local version history.

After staging the intended changes, create a commit with:

git commit -m "Describe the change"

The -m flag supplies a short commit message. The message should identify what the saved change represents so that the history remains understandable.

When Git is used for the first time on a computer, it may refuse to commit until the author's identity is configured. Git needs a name and email because this information is attached to commits.

Configure the identity for the computer with:

git config --global user.email "your-email@example.com" git config --global user.name "Your Name"

The --global flag applies the configuration across repositories on that computer.

To use repository-specific identity settings instead, use local configuration:

git config --local user.email "your-email@example.com" git config --local user.name "Your Name"

After a successful commit, Git reports a summary such as the number of files changed and lines added or removed. Running git status should then show a clean working tree if no new edits remain.

Display the full commit history with:

git log

The log includes commit identifiers, author information, dates, and commit messages.

Display a compact history with:

git log --oneline

This view shows shortened commit identifiers and messages, making it easier to scan the sequence of changes.

A commit identifier points to a specific saved state. The shortened identifier shown by --oneline can be used when it uniquely identifies the intended commit.

To inspect a previous project state, use:

git checkout <commit-id>

Git updates the working files to match that commit. The terminal reports a detached HEAD state because you are viewing a specific commit rather than working on the tip of a normal branch.

For example, if a later commit added a line to a file, checking out an earlier commit makes that line disappear from the working directory because the earlier saved state did not contain it.

Return to the latest state of the main branch with:

git checkout main

Before moving to an earlier commit, preserve pending work. Local changes that would be overwritten can prevent the checkout.

To compare two saved states, use:

git diff <commit-id-1> <commit-id-2>

The output identifies changed files and shows added and removed lines. Reversing the order of the commit identifiers reverses the comparison perspective.

This makes commit IDs useful for more than navigation. They also let you inspect precisely how the project changed between two points in history.

When Git opens a paged log or diff view, press Q to exit that view and return to the normal terminal prompt.

A repository history is only useful when its commits are understandable and inspectable.

Author identity answers who recorded a change. The commit message answers why or what was changed. The commit ID provides an exact reference to the saved state. The log shows how those states are ordered. Diff reveals the content-level difference between them.

Together, these features turn project history into an operational tool rather than a passive archive.

A disciplined commit cycle is:

1. Run git status.
2. Stage the intended changes.
3. Run git status again.
4. Commit with a descriptive message.
5. Run git status to confirm the working tree is clean.
6. Review recent history with git log --oneline.

git status git add . git status git commit -m "Add the third project file" git status git log --oneline

To inspect an earlier state:

git log --oneline git checkout <older-commit-id>

git checkout main

To compare two versions:

git diff <first-commit-id> <second-commit-id>

A commit saves only staged changes. Unstaged edits remain outside the commit.

A vague message weakens the usefulness of the log because the saved state has little explanation.

Checking out a commit is useful for inspection, but detached HEAD is not the same as returning to a normal development branch. Move back to a branch before continuing ordinary branch-based work.

The order of commit IDs affects diff output, so a confusing comparison may simply need the identifiers reversed.

A commit is a named, authored, uniquely identified saved state. Use status to verify it, log to locate it, checkout to inspect it, and diff to understand how it differs from another state.