Git cheatsheet

THE PRACTICAL GUIDE · NORMANDIN SYSTEMS

Get more from Git cheatsheet

Git Cheatsheet provides common commands for inspecting changes, staging content, committing history, and working with branches. Git distinguishes the working tree, staging area, and committed history. Knowing which layer a command reads or changes prevents confusion when a file is edited but not staged, or staged content differs from the latest working copy. A cheatsheet works best as a memory aid while you practice a concrete task. Read the command or syntax together with its arguments, placeholders, and surrounding context. Similar-looking options can have very different meanings, and an example written for one platform or version may need adjustment elsewhere. Keep the reference beside a small test case, use read-only examples first when possible, and check the relevant help output before applying an unfamiliar command to valuable files or a running service.

Guide updated October 13, 2026

How to use this tool

1. Identify the operation you want to perform and find the matching section of the reference. Read the whole example before copying any part of it.
2. Start by inspecting repository status and the relevant diff, then choose the command matching the layer you intend to affect.
3. Review the example below and compare its expected behavior with a small sample of your own input before continuing.
4. Try the adapted example on a small test case, compare the result with the explanation, and save the command with a note about the context in which it works.

SEE IT IN PRACTICE

A worked example

git status

A summary of branch state and staged, unstaged, or untracked files

Status establishes the current repository state before an operation that creates or rewrites history.

Understand the three places a change can exist

The working tree contains editable files, the index contains the proposed next snapshot, and commits contain recorded history. A file can have staged changes and additional unstaged changes simultaneously. Inspect the appropriate diff for the question you are answering rather than assuming one status entry describes a single version. Before committing, review the staged snapshot itself. This catches accidental omissions and unrelated files more reliably than reviewing only what the editor currently displays.

History-changing commands need scope awareness

Resetting, restoring, cleaning, rebasing, and force-pushing have different effects on files and history. A reference example is not enough to decide which operation fits a recovery problem. Establish the current branch, uncommitted work, and whether commits have been shared. Preserve recoverable work before destructive changes and use inspection tools to understand the state. A clear commit history and a clean working tree are useful goals, but they should not be pursued by discarding changes whose purpose has not been understood.

When this tool is useful

• Review staging and commit commands
• Understand the working tree versus index
• Find a safe inspection command before changing repository state

Tips for a better result

• Check the current branch, working-tree changes, and remote context before applying an unfamiliar example.
• Replace example paths, identifiers, and names deliberately. Copying a reference command unchanged can target a different file, branch, service, or environment from the one you intended.
• Keep the source and the settings used for this result together. That makes a later comparison or correction easier, especially when another person needs to reproduce the same outcome.

Frequently asked questions