Use this page when you need the right Git command quickly. Each task includes the command, a concrete example, and a practical warning where the command can be destructive or confusing.
git reset --soft HEAD~1Example: Use this after a commit with the wrong message or when you want to split the commit into smaller commits.
Gotcha: This rewrites local history. Do not use it on a commit that you already pushed to a shared branch unless you know the team impact.
git restore path/to/fileExample: Example: git restore resources/views/cheats/sheets.blade.php
Gotcha: This permanently drops your local edits for that file if they are not staged or backed up elsewhere.
git stash push -m "wip before deploy"
git stash popExample: Stash before switching branches, then restore the work after the urgent task is done.
Gotcha: Use a message so the stash is identifiable. `pop` removes the stash entry after applying it; use `apply` if you want to keep it.
git log --follow -- path/to/fileExample: Example: git log --follow -- app/Http/Controllers/Coding/CheatsheetController.php
Gotcha: The `--follow` flag helps across renames, but it works best for a single file path.
git diff main...feature/my-changeExample: Use the three-dot form to compare what your feature branch changes relative to the merge base.
Gotcha: Two-dot and three-dot diffs answer different questions. The three-dot form is usually the safer review view for pull-request style work.
Git is easy to use until you need to recover, compare, or explain history under pressure. That is why a task-first Git reference matters. Most developers do not struggle with git init or git add; they struggle when a branch is ahead, a file was restored incorrectly, a commit disappeared from view, or a merge sequence became confusing. This page focuses on those high-frequency questions.
If you have searched for Git reference, git references, GitHub Git, or even a downloadable Git cheat sheet, the useful layer is usually smaller than the full manual. You want the safe commands for current state, recent history, branch movement, and recovery. That is the layer this page emphasizes.
status, diff, or log again after each meaningful step.| Task | Command | Why it is useful |
|---|---|---|
| See branch and file state | git status -sb |
Compact status plus current branch |
| View recent commits | git log --oneline -n 10 |
Fast answer to “what changed recently?” |
| Compare unstaged changes | git diff |
Review edits before staging |
| Compare staged changes | git diff --staged |
Verify what will go into the next commit |
| Create and switch branch | git switch -c feature/name |
Safer mental model than older multi-purpose commands |
| Restore a file from HEAD | git restore path/to/file |
Undo working tree changes without branch jumps |
| Inspect movement history | git reflog |
Recovery tool when commit pointers moved |
| See where a name points | git show-ref |
Lists Git references such as branches and tags |
```bash
git status -sb
git log --oneline -n 10
git diff
git diff --staged
```
This sequence answers four separate questions: where you are, what happened recently, what changed but is not staged, and what is already staged. Running these commands in order reduces most Git confusion because you stop guessing. A large percentage of Git mistakes come from acting before inspecting.
checkout versus switch versus restoreOlder Git tutorials often center everything around git checkout, but modern Git is easier to reason about when you split its responsibilities. Use git switch for branch movement and git restore for file content recovery. This avoids overloading one command with too many meanings.
That does not mean git checkout is wrong. It still exists and still matters. But if your actual question is “when should I use git checkout?”, the best practical answer is: use it mostly when you already know the older workflow or when you need a legacy-compatible command. For daily work, switch and restore communicate intent more clearly.
A common need is not just seeing the last 10 commits, but seeing them in a form that supports action. git log --oneline -n 10 is the fast answer. If you need more context, add --decorate --graph --stat. The point is to move from raw history to a shape you can reason about.
```bash
git log --oneline --decorate --graph -n 10
```
This helps you answer:
Git recovery is usually pointer recovery. The data is often still there; you just lost sight of the reference that reached it. That is why git reflog is so valuable. Reflog records where HEAD and branch references pointed over time. If you switched, reset, rebased, or checked out the wrong thing, reflog often gives you the commit you need to return to.
```bash
git reflog
git switch -c rescue-branch
```
Creating a rescue branch before more destructive operations is a good habit. It gives you a named place to investigate from, especially when you are working quickly and want to avoid a second mistake while fixing the first.
The phrase “Git reference” can mean two things. Informally, it means a guide like this one. Internally, a ref is a name that points to an object, most often a commit. Branches and tags are references. That is why commands like show-ref and terms like refs/heads/main exist. Knowing this helps when output mentions refs directly.
You do not need deep internals to be productive, but understanding that branches are movable references makes many Git behaviors much less mysterious.
git checkout?Use it mainly when you are following an older workflow or need a behavior not yet split into switch and restore in your habits. For daily clarity, prefer git switch for branches and git restore for files.
Run git log --oneline -n 10. Add --decorate --graph if you want branch markers and a clearer history shape.
Inspect first. status, log, and diff prevent more mistakes than any “magic” recovery command.
Check git reflog before assuming the commit is gone. In many cases, the commit still exists and you only need to create or move a reference back to it.
Use the Bash reference for shell-level repository automation, the Linux command reference for file and permission inspection around a repo, the VS Code shortcut reference for navigating symbols while reviewing code, or the Developer Reference Hub to jump between adjacent workflows. Git moves fastest when the rest of your toolchain is equally easy to recall.
Before software can be reusable it first has to be usable.
…
…