Git CLI Cheat Sheet

Git Command Line Mastery: A Comprehensive Reference

This cheat sheet is designed to serve as your daily companion when working with Git. While there are graphical tools available, the command line remains the most powerful and universal way to interact with Git. Every feature available in Git is accessible through the CLI, and commands execute instantly without the overhead of a graphical interface.

The commands are organized by workflow stage—from initial setup to daily operations to branching to recovery. This mirrors how you actually work with Git: you set things up once, perform daily operations repeatedly, branch for features, and occasionally need to undo mistakes.

Why the Command Line Matters

Graphical Git clients are excellent for visualization—seeing branch history, reviewing diffs, and resolving merge conflicts. But the command line offers advantages that no GUI can match. It is scriptable, allowing you to automate repetitive tasks. It is consistent across platforms—the same commands work on Windows, Mac, and Linux. It is available everywhere, including on remote servers via SSH where there is no graphical interface. And it is simply faster once you know the commands.

More importantly, understanding the command line means understanding what Git is actually doing. GUIs abstract away the underlying operations, which can leave you confused when something goes wrong. When you know the CLI, you can debug issues, recover from mistakes, and understand error messages.

Configuration That Saves Time

Git stores configuration at three levels: system (all users), global (your user account), and local (current repository). The --global flag sets options for your user account, which is appropriate for your name, email, and personal preferences. Local configuration (no flag) overrides global settings for specific projects.

Beyond the basic name and email, consider setting up aliases for commands you use frequently. git config --global alias.co checkout lets you type git co instead of the full command. git config --global alias.st status is another popular one. Some developers create aliases for complex commands like git log --oneline --graph --all.

The default text editor for commit messages is often Vim, which can be confusing if you are not familiar with it. You can change this with git config --global core.editor "code --wait" for VS Code, or specify any editor you prefer.

The Staging Area in Depth

The staging area (also called the index) is Git's killer feature that many version control systems lack. It sits between your working directory and the repository, allowing you to compose commits carefully. You can stage individual files, stage parts of files, review what is staged before committing, and adjust as needed.

git add -p (patch mode) is incredibly powerful. It shows you each chunk of changes and asks whether to stage it. You can stage some changes to a file while leaving others unstaged—perfect when you have been working on multiple things and want to separate them into distinct commits.

git diff shows unstaged changes (working directory vs staging area). git diff --staged shows staged changes (staging area vs last commit). Understanding this distinction helps you verify exactly what will be in your next commit.

Branching Strategies

Git branches are lightweight pointers to commits, costing almost nothing to create. This enables workflows that would be impractical with heavier version control systems. The most important habit is to always work on a branch—never commit directly to main.

The modern commands git switch and git restore were introduced to clarify the overloaded git checkout command. switch changes branches, restore restores files. The older checkout still works and does both, but the new commands are clearer.

When merging, conflicts occur when the same lines were changed in both branches. Git marks these conflicts in the files with <<<<<<, ======, and >>>>>> markers. You need to edit the files to resolve conflicts, then stage and commit the result.

Recovery and Undo Operations

Git provides multiple ways to undo things, each appropriate for different situations. The key is understanding what state you are trying to return to and whether you have already pushed changes.

For uncommitted changes: git restore file (or git checkout -- file) discards changes in the working directory. git restore --staged file (or git reset HEAD file) unstages changes but keeps them in the working directory.

For committed but not pushed changes: git reset --soft HEAD~1 moves the branch pointer back but keeps changes staged. git reset --mixed HEAD~1 (the default) keeps changes but unstages them. git reset --hard HEAD~1 discards changes entirely—use with caution.

For pushed changes: git revert is the safe option because it does not rewrite history. It creates a new commit that undoes the changes from a previous commit. This is the appropriate choice for shared branches where others may have based work on the commits you want to undo.

The Power of Git Stash

git stash is indispensable when you need to quickly switch contexts. Perhaps you are in the middle of a feature when an urgent bug comes in. Stash saves your work-in-progress, giving you a clean working directory. Switch to main, fix the bug, then return to your feature branch and git stash pop to continue where you left off.

You can have multiple stashes, listed with git stash list. Apply a specific stash with git stash apply stash@2. Add a message for clarity: git stash push -m "work on user auth". Stash even works across branches, though be careful about potential conflicts.

Working with Remotes

A remote is a connection to another repository, usually on a server. origin is the conventional name for the primary remote, created automatically when you clone. You can add additional remotes for collaborating with forks or managing multiple servers.

git fetch downloads new commits from the remote without integrating them. This is safe—it only updates your remote-tracking branches (like origin/main). git pull fetches and then merges, which can create merge commits or conflicts.

Many teams prefer git pull --rebase, which replays your local commits on top of the remote changes instead of merging. This keeps the history linear but requires that you have not pushed the commits being rebased.

Viewing History

git log shows commit history, but the raw output is often overwhelming. git log --oneline shows a compact view. git log --graph shows branch structure. git log --all shows all branches. Combine them: git log --oneline --graph --all gives a clear overview of your entire repository structure.

git blame file shows who last changed each line—invaluable for understanding why code was written a certain way. git show commit displays the contents of a specific commit. git diff commit1 commit2 shows what changed between two points.