Git Commands Cheat Sheet
The most used Git commands organized by category. Copy any command with a single click.
đ¤ Commonly Confused Git Commands
Commands that look or sound similar but behave very differently in practice. Picking the wrong one â especially on a shared branch â can destroy your teammates' work, so it's worth understanding the distinctions before you run them.
1. git merge vs git rebase
Both combine changes from two branches, but they treat history in fundamentally different ways.
| Aspect | git merge | git rebase |
|---|---|---|
| History shape | Preserves divergence and join | Rewrites as a straight line |
| Merge commit | Created (by default) | Not created |
| Commit SHAs | Preserved | Rewritten (changed) |
| Shared branches | â Safe | â ī¸ Never rebase pushed commits |
| When to use | Integrating feature â main | Cleaning up a personal branch, rebasing onto latest main |
đĄ Bottom line: Use merge for shared/official branches, rebase for tidying up a personal branch. Rebasing commits that are already pushed rewrites their SHAs and breaks your collaborators â don't do it.
2. git reset vs git revert
Both feel like "undo a commit", but only one actually preserves history.
| Aspect | git reset | git revert |
|---|---|---|
| Mechanism | Moves HEAD backward (discards commits) | Adds a new commit that undoes the changes |
| History | Commits disappear | Original + undo commit remain |
| Shared branches | â ī¸ Requires force push, risky | â Safe with a normal push |
| When to use | Cleaning up local commits not yet pushed | Safely undoing an already-pushed commit |
đĄ Bottom line: reset is clean on local-only history, but on shared branches always use revert. reset --hard followed by a force push is the single most dangerous Git sequence for team workflows.
3. git pull vs git fetch
Both bring remote changes into your repo, but one merges automatically while the other doesn't.
| Aspect | git fetch | git pull |
|---|---|---|
| Downloads remote changes | â | â |
| Merges into current branch | â Manual step | â Automatic (fetch + merge) |
| Unexpected merge commits | None | Possible |
| When to use | Inspecting remote state before merging | Quickly syncing and continuing work |
đĄ Bottom line: pull = fetch + merge. For a safer workflow, git fetch first, review with something like git log origin/main..HEAD, then merge manually. If you prefer linear history, configure git pull --rebase as your default.
4. git reset --soft vs --mixed vs --hard
The same reset command does wildly different things depending on the flag â specifically, how far back it rolls the state.
| Flag | HEAD | Index (staging) | Working tree | When |
|---|---|---|---|---|
--soft | Moved | Kept | Kept | Undo a commit to rewrite its message |
--mixed (default) | Moved | Reset | Kept | Unstage changes but keep the edits |
--hard | Moved | Reset | Reset â ī¸ | Throw everything away, back to that commit |
đĄ Bottom line: --hard destroys uncommitted work, so always run git status first. If you wipe something by mistake, git reflog can often recover recent HEAD positions.
5. git stash pop vs git stash apply
Both restore your stashed changes; the difference is whether the stash gets removed from the list.
| Aspect | git stash pop | git stash apply |
|---|---|---|
| Restores changes | â | â |
| Stash list | Removed | Kept |
| Reuse across branches | Not possible (one-shot) | Possible |
| When to use | Applying once and moving on | Testing the same change in multiple places |
đĄ Bottom line: Unless you're certain the stash is no longer needed, apply is safer. If pop hits a conflict, the changes come back but the stash may already be gone. For anything important, prefer apply â verify â manual drop.
đ§ What command for what situation? (Scenario index)
- Fix the message of the commit I just made â
git commit --amend -m "new message"(before pushing) - Undo the last commit (not pushed yet) but keep changes â
git reset --soft HEAD~1 - Safely undo a commit that's already pushed â
git revert <commit>(preserves history) - Park work-in-progress to switch branches â
git stash -uâ âĻ âgit stash pop - Create and switch to a new branch â
git switch -c <name> - First push of a local branch â
git push -u origin <branch> - Rebase my branch on top of latest origin/main â
git fetch origin && git rebase origin/main - Cancel an in-progress merge â
git merge --abort - Cancel an in-progress rebase â
git rebase --abort - Force push but protect collaborators' commits â
git push --force-with-lease - Restore a single file to its committed state â
git restore <file> - Recover a deleted branch or commit â
git reflogâgit checkout <sha> - Who last edited this line? â
git blame <file> - Tag and push a release v1.2.0 â
git tag -a v1.2.0 -m "release"âgit push origin v1.2.0
đ Git workflow & core concepts
The basic Git flow moves changes through Working Directory â Staging Area â Local Repository â Remote Repository.
git add- moves changes from working directory to staging areagit commit- records staged changes into the local repositorygit push- uploads local commits to the remote repositorygit pull- fetches and merges changes from remote into local
Core Concepts (Quick Reference)
- Branch - An independent line of development that diverges from the main flow. Lets you build features or experiment without affecting the main code.
- Merge - Combines changes from two branches. Both histories are preserved and a merge commit may be created.
- Rebase - Moves your branch's commits to be re-applied on top of another branch's latest commit. Result is similar to merge but the history stays linear. Avoid rebasing already-shared commits, as it can cause conflicts for collaborators.
- Stash - Temporarily saves uncommitted changes in a "drawer" so you can switch branches without losing work. Pop it back when you're ready to continue.
- Checkout / Switch - Move to another branch or specific commit. Modern Git splits this into
git switch(branch switching) andgit restore(file recovery) for clarity. - Reset - Moves commits back to a past point. It rewrites history, so it's risky on shared branches.
--softkeeps changes;--harddiscards everything. - Revert - Creates a new commit that undoes a specific commit's changes. History is preserved, making this the safe way to undo on shared branches.
- Fetch vs Pull - fetch only downloads remote changes; pull does fetch + automatic merge into the current branch.
pull = fetch + merge. - HEAD - A pointer to the latest commit on the current branch.
HEAD~1is the previous commit;HEAD~3is three commits back. - Fast-forward - When merging, if only one side has new commits since divergence, Git simply moves the branch pointer forward without creating a merge commit.
- Tag - A meaningful name (usually a version number) attached to a specific commit. Mostly used to mark release points.
â Frequently Asked Questions
What is the difference between git fetch and git pull?
fetch only downloads remote changes, while pull downloads and automatically merges them into the current branch. pull = fetch + merge.
What is the difference between git reset and git revert?
reset rewrites history by moving commits back, while revert adds a new commit that undoes the changes, preserving history. Use revert on shared branches.
Should I use merge or rebase?
merge preserves history as-is; rebase creates a clean linear history. Use merge for public branches and rebase for personal branches as a general rule.
How do I undo a commit I accidentally pushed?
If the branch is shared, use git revert to add an undo commit. Avoid git reset --hard followed by force push, since it can break your collaborators' work.
Should I use git switch or git checkout?
Modern Git splits checkout into git switch (branch switching) and git restore (file recovery). Use switch/restore in new code; checkout remains for compatibility.