Common Git commands are the small, recurring set of instructions developers run every day to initialize a repository, inspect its state, stage files, record commits, switch branches, and exchange work with remotes. A focused search-and-copy reference collapses that recurring set into one place so you spend less time guessing syntax and more time reading what your repository is actually doing. The twelve most-used templates cover the full everyday loop: starting or cloning a repo, checking status with a compact flag, viewing the unstaged diff, reading a decorated log, adding a specific path, committing staged content with a message, naming the current branch, switching or creating branches, fetching with prune, and pushing with an upstream tracking reference. Each template is shown as a copyable string with angle-bracket placeholders for values like <url>, <path>, <message>, and <branch> that you replace before running anything. The list is intentionally narrow — it favors the explicit modern commands and inspect-first habits that work the same way across Git versions, rather than a sprawling catalog of aliases, history-rewriting recipes, or destructive operations that demand stronger context and recovery planning.
The full list lives in the Git Cheat Sheet, which searches twelve source-checked Git commands by category, command, or workflow purpose. Open it once, type the workflow you are about to run, and copy only the line you need after checking the placeholder, branch, and remote context.
What the Twelve Core Git Commands Cover
The reference is built around the recurring loop a developer actually performs: start or copy a repository, look at what changed, stage the right paths, record a commit, branch off or merge back, and share work with a remote. Every entry in the table below maps to one of those steps and uses the explicit modern command that the official Git reference manuals document as the recommended form.
| Workflow step | Template | What it does |
|---|---|---|
| Initialize | git init | Create an empty repository in the current directory. |
| Clone | git clone <url> | Copy a remote repository into a new local directory. |
| Compact status | git status --short | Summarize tracked, staged, modified, deleted, and untracked paths on two columns. |
| Unstaged diff | git diff | Show changes in the working tree that are not yet in the index. |
| Decorated log | git log --oneline --decorate --graph -n 10 | Print ten commits with branch and tag markers for quick context. |
| Stage a path | git add <path> | Move a specific file or directory into the index, narrower than staging the whole tree. |
| Commit staged | git commit -m <message> | Record the staged snapshot with a message that describes the intent. |
| Current branch | git branch --show-current | Print the name of the branch checked out in this working copy. |
| Switch branch | git switch <branch> | Move to an existing local branch. |
| Create and switch | git switch -c <branch> | Create a new local branch and check it out in one step. |
| Fetch with prune | git fetch --prune | Download remote refs and drop stale remote-tracking names without merging. |
| Push with upstream | git push -u origin <branch> | Publish the current branch and record the upstream tracking reference. |
Four of these entries — git status --short, git diff, the compact decorated log, and git branch --show-current — are inspection commands that change nothing in the repository. Two of them — git init and git clone — start a working copy. Two more — git add and git commit — record work locally. The remaining four — git switch, git switch -c, git fetch --prune, and git push -u — change branches or remote state. Network-touching operations include clone, fetch, and push, each written in their explicit, recoverable form. Force push, hard reset, clean, rebase, and history rewriting are intentionally excluded; the Atlassian Git tutorials cover those recipes in a context-rich form that does not belong in a quick-copy list.
How to Search and Copy a Safe Template
The cheat sheet is a local, read-only reference. It does not run Git, open a repository, upload data, or store commands you copy, and it requires no login. Use it as a four-step routine:
- Search by command, category, or task. Type a word such as commit, branch, remote, or staged to narrow the twelve entries to the one that matches the workflow you are about to run.
- Read the description that sits next to the template and confirm the command really matches the situation — for example, git diff for unstaged work and git diff --cached for content already in the index.
- Replace every angle-bracket placeholder such as <url>, <path>, <message>, or <branch> with a value appropriate to the repository and shell. Do not type the angle brackets literally. Quote any path or message that contains spaces or shell-sensitive characters.
- Copy the command only after confirming the working directory, current branch, configured remotes, staged diff, and any repository instructions, then inspect the resulting status, diff, commit, or remote state after execution.
A copied command is not automatically safe merely because its syntax is valid. The repository, shell, permissions, hooks, and collaboration policy remain your responsibility. If the template looks right but the description warns that it can rewrite history, drop the change and read the long-form manual instead — the cheat sheet already filtered those recipes out for that reason.
Placeholder and Shell-Safety Rules
Every angle-bracket token in a template is a placeholder, not a literal character. Replace <url> with the remote URL, <path> with the relative or absolute path inside the repository, <message> with a short sentence that explains the intent, and <branch> with the local or remote-tracking branch name. Wrap any value that contains spaces, shell metacharacters, or quotes in single or double quotes according to your shell rules. Never paste secrets into commit messages, remote URLs, or branch names.
Some workflow pitfalls are easy to miss in a quick-copy setting. git add <path> is deliberately narrower than staging the whole tree: review exactly what entered the index, especially in a shared checkout that contains generated files, credentials, databases, or unrelated user work. A commit records staged content, not every visible change, so write a message that explains intent and keep logically separate work in separate commits. Hooks can modify or reject a commit, so inspect the final commit after it succeeds rather than assuming the staged snapshot remained unchanged. Output describes repository state at a moment in time; another process, editor, hook, or collaborator can change files or references afterward, which is why the routine ends with a re-check immediately before any commit or push.
Inspect-Before-Mutate Habits
Inspection commands should come before mutation. Read the compact status, scan the unstaged diff, and skim the decorated log before running anything that moves files into the index, records a commit, switches branches, fetches new refs, or pushes a branch upstream. The compact decorated log example shows ten commits with branch and tag markers, but deeper history or a path-limited log may be needed for diagnosis — pass a path or a larger -n value when the default view hides the context you need.
Branch and remote operations affect collaboration even when they look local. git switch -c <branch> creates a local branch; git push -u origin <branch> publishes it and records the upstream tracking reference so future git pull and git push calls know where to go. git fetch --prune downloads references and removes stale remote-tracking names without merging into the current branch, but pruning can make deleted remote branches disappear from the local tracking view, so confirm the remote URL and access policy before running it on a shared checkout. The full inspect-first routine is described in the inspect-first workflow guide, which expands the same twelve commands into a daily checklist.
What the Reference Deliberately Omits
A cheat sheet earns its value by what it leaves out as much as what it includes. Force push, hard reset, clean, rebase, and history rewriting recipes are omitted because they can discard or rewrite work and require repository-specific recovery planning — a context-free quick-copy list is the wrong place for them. If a team workflow needs signed commits, protected branches, pull requests, or different remote names, the templates still serve as a starting point, but you confirm the convention with project documentation and a recoverable backup or branch before any unfamiliar change. Git versions and organizational policy can differ, so consult git help <command> and the long-form manuals when a template is new to you.
When automation invokes Git, pin the working directory, handle exit codes, and capture enough non-sensitive output to diagnose partial failure without exposing credentials. The cheat sheet never runs Git, opens a repository, uploads data, or stores commands; it is local and read-only until you choose to copy text. Twelve entries are checked for unique IDs and command templates against upstream documentation and an independent tutorial source, but no reference can replace the practice of reading the actual output of your repository before every commit and push.