Everyday Git Commands: Inspect, Commit, Integrate, and Undo

Key takeaways

• Inspect status and diffs before deciding which Git operation fits the current state.
• Staging records selected content for the next commit, not every later edit to the file.
• Fetch updates your view of remote history without merging it into your working branch.
• Unstaging, discarding edits, and reverting a shared commit are different operations.

Everyday Git becomes easier when commands correspond to four places: the working tree, the staging area, local commit history, and another repository.

Imagine fixing validation in a checkout form while an unrelated documentation edit remains unfinished. The goal is to record and share the fix without accidentally including that other work.

The examples below assume an existing repository with a remote named origin and a main branch named main. Substitute the names and paths used by your project.

Inspect Before Changing State

git status
git diff
git diff --staged

Status identifies the current branch, changed files, and operations in progress. The ordinary diff shows tracked changes not staged; the staged diff shows what the next ordinary commit would record relative to the current commit.

Untracked files appear in status but are not included in an ordinary diff. Inspect their contents separately before staging them.

For a history overview:

git log --oneline --graph --decorate -10

This gives context before you start adding commits.

Put the Fix on a Branch

Starting from the intended base, create a branch:

git switch -c fix/checkout-validation

A branch names a line of history. Creating it does not automatically isolate unrelated uncommitted edits, so the documentation change can still be present.

If switching would overwrite conflicting local work, Git may refuse. Preserve or commit that work deliberately instead of treating the refusal as a reason to force the switch.

The version-control guide explains the broader relationship between branches and shared history.

Stage the Change You Want to Record

git add -- src/checkout.js
git diff --staged
git commit -m "Reject empty checkout addresses"

The git add documentation explains that staging captures content at the time the command runs. If you edit the file again, that later edit remains unstaged until added.

For separate changes within one file, git add -p lets you select hunks interactively. Keep the resulting commit coherent: a patch selection can accidentally omit a dependency.

The documentation edit remains outside this commit because it was not staged. Review the project’s relevant behavior before recording a change; a clean Git diff is not proof of correctness.

Fetch Before Deciding How to Integrate

git fetch origin
git log --oneline --graph --decorate --all -15

Fetch retrieves remote objects and updates configured remote-tracking references. It does not automatically merge origin/main into the feature branch.

After preserving unrelated uncommitted work, one integration option while on the feature branch is:

git merge origin/main

That brings the fetched main-branch history into the current branch. Teams may instead use rebase, which recreates commits on a different base and therefore changes their identities.

Follow the team’s policy for published branches. A rejected push is not, by itself, a reason to force-push.

Resolve Conflicts as Code Changes

When a merge stops, run git status and inspect the affected files. Decide what the combined behavior should be, remove conflict markers, and stage the resolution.

git add -- src/checkout.js
git merge --continue

Use git merge --abort if you need to abandon the merge. Starting an integration with preserved, clean work makes recovery clearer.

An automatic merge can still introduce a semantic bug. Two compatible text edits may disagree about how a function should behave.

Publish the Branch

git push -u origin fix/checkout-validation

The first push publishes the branch and sets its upstream. It does not merge the branch into main or automatically create a review request.

Use the team’s review process to explain the change, its validation, and any migration concerns. The remote branch now provides a shared revision for that discussion.

Match Undo to the Intended Outcome

Intent	Command example	Result
Unstage a file	git restore --staged -- src/checkout.js	Keeps working-tree edits
Discard unstaged tracked edits	git restore -- src/checkout.js	Replaces working content from the index by default
Reverse a shared ordinary commit	git revert COMMIT_ID	Creates a new inverse commit

The restore manual documents its source and destination defaults. Discarded working-tree edits may not be recoverable from Git.

Revert preserves the original commit in history and can itself encounter conflicts. Merge commits need additional interpretation, so the ordinary example should not be applied blindly to them.

For the checkout fix, inspect first, stage intentionally, and distinguish publishing from integration. Those habits make the command sequence understandable when the next change is less straightforward.

Before choosing an undo command, establish where the work exists and whether anyone else depends on it.