Git Without Fear: A Working Engineer's Field Guide

Git becomes less scary when you stop treating it as a bag of commands and start thinking in states.

Your working tree contains the files you are editing. The index—or staging area—holds the exact changes you intend to include in the next commit. A commit is a snapshot in project history, linked to its parent commit. Branches are movable names pointing to commits.

That model explains most day-to-day Git work.

The everyday loop

Inspect → Edit → Review diff → Stage deliberately → Commit → Share

Start with:

git status --short
git diff

git status tells you what is changed, staged, untracked, or unresolved. git diff shows unstaged changes. After staging, git diff --staged shows what the next commit would contain.

Use the index deliberately:

git add path/to/the-file
git diff --staged
git commit -m "fix: handle repeated checkout requests"

You can stage selected files or even selected hunks. Before committing, check that secrets, generated files, unrelated changes, and debugging leftovers are not included.

Branches are movable pointers, not copies of the whole project

A branch gives a change its own line of development. A common workflow is:

git switch -c fix/duplicate-checkout
git status --short
# make and verify the change
git add path/to/changed-files
git commit -m "fix: prevent duplicate checkout orders"

Use the naming convention your team expects. Before switching branches, check whether you have uncommitted changes and understand what will happen to them. Git often refuses unsafe operations, but you should not rely on it as your only protection.

Read the graph when history gets confusing

git log --oneline --graph --decorate -12
git show --stat HEAD
git diff main...HEAD

These commands show recent history, the latest commit’s file-level impact, and the changes on your branch relative to its common ancestor with main (assuming main is the target branch). Replace branch names to match your repository.

Common problems, safely handled

“I staged the wrong file.”

If the commit has not happened yet, git restore --staged path/to/file removes the file from the index without discarding the working-tree edits. Then inspect git status again.

“I want to understand what changed.”

Run git diff for unstaged changes and git diff --staged for staged changes. Do not blindly stage everything with git add . when you are unfamiliar with the repository or have generated files and secrets in your working tree.

“I made a bad local commit.”

Pause and inspect the situation before running a reset. If the commit is local and unshared, you have options—but the safest choice depends on whether you want to keep the changes, unstage them, or discard them. git revert creates a new commit that reverses a prior commit and is often safer for changes already shared with others.

“I have merge conflicts.”

A conflict means Git could not determine how to combine changes automatically. Open each conflicted file, understand both versions, produce the intended result, run relevant tests, and then mark the conflict resolved. Never choose “accept all incoming” or “accept all current” without understanding the effect.

“I found a destructive command online.”

Commands such as git reset --hard, git clean -fd, and force-pushes can discard work or alter shared history. Before using one, inspect status, understand exactly what it will affect, and preserve needed changes. If you cannot explain the command’s effect, do not run it yet.

A small set of commands worth knowing

Goal	Command
Inspect changes	git status --short
View unstaged diff	git diff
View staged diff	git diff --staged
See recent history	git log --oneline -10
Inspect a commit	git show <commit>
Create a branch	git switch -c <name>
Undo staging, keep edits	git restore --staged <path>
Reverse a shared commit	git revert <commit>

Commands have context-dependent effects. For exact semantics, use the official Git docs linked above. In particular, distinguish undoing a change in your working tree, moving a branch pointer, and creating a new commit that reverses history. They are not interchangeable.

Your safety habit

Before any command that might discard or rewrite work, run git status --short and ask: what state do I want to preserve, and what state do I intend to change?

That tiny pause is more useful than memorizing a hundred recovery commands.

Git confidence is mostly the ability to inspect state before acting—and to choose an operation whose consequences you understand.