Git Cheatsheet - Complete Reference 2025

This cheatsheet provides a comprehensive, quick-reference guide to Git, covering essential commands, advanced operations, workflow best practices, and troubleshooting tips. It’s designed for developers needing fast, accurate information for real-world development scenarios as of December 2025.

Quick Reference: Most Used Commands

Getting Started & Configuration

Setup

Basic Configuration

These settings are global unless --local is specified.

Basic Commands

Staging and Committing

Checking Status and History

Remote Operations

Branching & Merging

Branch Management

Switching Branches

Merging Branches

Resolving Merge Conflicts

When Git cannot automatically merge changes, you’ll encounter a conflict.

Use Case: Merging feature/A into main, both branches modified the same line in file.txt.

1. Initiate Merge:

   git checkout main
   git pull origin main # Ensure main is up-to-date
   git merge feature/A
   

   Git will report conflicts, e.g., CONFLICT (content): Merge conflict in file.txt.

2. Identify Conflicts: Open the conflicted file (file.txt). You’ll see conflict markers:

   <<<<<<< HEAD
   This is the line from main.
   =======
   This is the line from feature/A.
   >>>>>>> feature/A
   

   • <<<<<<< HEAD: Changes from the current branch (main).
   • =======: Separator.
   • >>>>>>> feature/A: Changes from the branch being merged (feature/A).

3. Resolve Conflicts: Edit the file to the desired state, removing all conflict markers.

   This is the resolved line, combining both changes.
   

4. Stage Resolved Files:

   git add file.txt
   

   Repeat for all conflicted files.

5. Commit Merge:

   git commit -m "Merge feature/A into main, resolved conflicts"
   

   Git pre-populates a merge commit message; you can modify it or save as is.

Advanced Operations

Stashing Changes

Temporarily saves changes that are not ready to be committed.

Rebasing

Rewrites commit history by moving or combining commits. Use with caution, especially on shared branches.

Concept: git rebase

# Syntax
git rebase [options] [base]

Explanation: Reapplies commits from your current branch onto another base branch. It creates a linear history by moving your branch’s commits to the tip of the base branch. Use Case:

• To keep your feature branch up-to-date with main before merging, creating a clean, linear history.
• To squash multiple small commits into a single, meaningful commit.

Example: Rebase feature/X onto main

git checkout feature/X
git rebase main

If conflicts occur during rebase:

1. Resolve conflicts in the file(s).
2. git add <resolved-file>
3. git rebase --continue To abort a rebase:

git rebase --abort

Interactive Rebase

Concept: git rebase -i (interactive)

# Syntax
git rebase -i [commit-hash or HEAD~N]

Explanation: Allows you to modify individual commits in a series. Git opens an editor with a list of commits and actions (pick, reword, edit, squash, fixup, drop). Use Case:

• Cleaning up messy commit history before pushing or merging.
• Squashing multiple small commits into one.
• Rewording commit messages.
• Reordering commits.
• Deleting commits.

Example: Interactive rebase on the last 3 commits

git rebase -i HEAD~3

This will open an editor with something like:

pick 76f8e9c Add user model
pick a1b2c3d Fix typo in user controller
pick d4e5f6g Implement user authentication

# Rebase 5a6b7c8..d4e5f6g onto 5a6b7c8 (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to re-use the given commit's
# .       message but edit it.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#

Change pick to squash or fixup to combine commits, reword to change messages, or drop to remove. Save and exit the editor.

Undoing Changes & Recovery

Unstaging Files

Discarding Local Changes

Amending Commits

Reverting Commits

Concept: git revert

# Syntax
git revert <commit-hash>

Explanation: Creates a new commit that undoes the changes introduced by a specified commit. It’s a safe way to undo changes on shared history because it doesn’t rewrite history. Use Case: Undoing a bad commit that has already been pushed to a shared remote repository.

Example: Revert a specific commit

git revert a1b2c3d # Reverts commit a1b2c3d, creating a new commit

Resetting Commits

Concept: git reset

# Syntax
git reset [--soft | --mixed | --hard] <commit-hash or HEAD~N>

Explanation: Moves the current branch’s HEAD to a specified commit. This rewrites history and should be used with extreme caution on shared branches. Use Case: Undoing local commits that haven’t been pushed yet, or cleaning up local history.

Using Reflog for Recovery

Concept: git reflog

# Syntax
git reflog [show]

Explanation: Records every change to HEAD (e.g., commits, merges, rebases, resets). It’s a powerful safety net for recovering lost commits or states. Use Case: Recovering from an accidental git reset --hard or a failed rebase.

Example:

1. View reflog:

   git reflog
   

   Output might look like:

   a1b2c3d HEAD@{0}: commit: Add feature X
   e4f5g6h HEAD@{1}: rebase (finish): returning to refs/heads/main
   ...
   

2. Identify the desired state (e.g., e4f5g6h).
3. Reset to that state:

   git reset --hard e4f5g6h
   

   This will restore your repository to the state it was at that point in the reflog.

Tagging

Common Patterns & Workflows

Feature Branch Workflow

1. Update main (or develop):

   git checkout main
   git pull origin main
   

2. Create a new feature branch:

   git checkout -b feature/my-new-feature
   

3. Develop and commit:

   # Make changes
   git add .
   git commit -m "feat: implement X"
   

4. Keep branch updated (optional but recommended):

   git checkout main
   git pull origin main
   git checkout feature/my-new-feature
   git rebase main # Or git merge main, if preferred for history
   

5. Push to remote:

   git push -u origin feature/my-new-feature
   

6. Create a Pull Request (PR): On GitHub/GitLab/Bitbucket.
7. Merge: After review, merge feature/my-new-feature into main.

Squashing Commits Before Merge/Push

To maintain a clean history, squash multiple small commits into one meaningful commit before merging or pushing.

git checkout feature/my-feature
git rebase -i HEAD~N # N is the number of commits to squash
# In the editor, change 'pick' to 'squash' or 'fixup' for subsequent commits
# Save and exit. Git will prompt for a new commit message.
git push origin feature/my-feature --force # Use --force only if already pushed and you know what you're doing

Warning: Force-pushing rewrites history. Only do this on branches that you are the sole developer on, or after coordinating with your team.

Keeping Local Branch Updated

To ensure your local branch has the latest changes from the remote:

git checkout main # Or your base branch, e.g., develop
git pull origin main

Then, if on a feature branch:

git checkout feature/my-feature
git rebase main # Applies your changes on top of the latest main
# OR
git merge main # Creates a merge commit

Tips & Tricks

Git Aliases

Shorten frequently used commands.

git config --global alias.co checkout
git config --global alias.br branch
git config --global alias.ci commit
git config --global alias.st status
git config --global alias.lg "log --graph --oneline --decorate --all"

Now you can use git co, git br, git ci, git st, git lg.

.gitignore

Specify intentionally untracked files that Git should ignore.

# Example .gitignore content
# Logs
*.log
npm-debug.log*

# Dependencies
node_modules/
.venv/

# IDE files
.idea/
.vscode/

# Build artifacts
build/
dist/

Commit Message Best Practices

• Subject Line: Concise summary (50-72 chars), imperative mood, no period.
  • feat: Add user authentication module
  • fix: Resolve login button responsiveness
• Body (optional): More detailed explanation, why the change, what problem it solves.
• Conventional Commits: Use prefixes like feat:, fix:, chore:, docs:, style:, refactor:, test:, perf:, ci:.

Interactive Staging

Stage only parts of a file.

git add -p <file>

Git will present hunks (sections of changes) and ask whether to stage them (y/n/a/d/g/e/?).

Viewing Diffs

Common Errors & Fixes

Collaboration Workflows & Best Practices

1. Feature Branching: Always work on dedicated branches for new features, bug fixes, or experiments. Never commit directly to main (or develop).
2. Pull Requests (PRs)/Merge Requests (MRs): Use PRs/MRs for code review and discussion before merging changes into main integration branches.
3. Small, Atomic Commits: Each commit should represent a single logical change. This makes history easier to understand and revert if needed.
4. Descriptive Commit Messages: Follow conventional commit guidelines (feat:, fix:, etc.) and provide clear, concise messages.
5. Rebase vs. Merge:
   • Merge: Preserves history, including merge commits. Good for public, shared branches (e.g., merging feature into main).
   • Rebase: Creates a linear history by rewriting commits. Good for cleaning up personal feature branches before merging into a shared branch. Never rebase a public/shared branch.
6. Keep Branches Up-to-Date: Regularly pull from the main integration branch (main/develop) into your feature branch (using git pull --rebase or git fetch then git rebase) to minimize merge conflicts.
7. Use .gitignore: Prevent unnecessary files (e.g., node_modules, .env, build artifacts) from being tracked.
8. Review Code: Actively participate in code reviews, providing constructive feedback and learning from others.
9. Don’t Force Push Shared Branches: Force pushing (git push --force) rewrites history and can cause significant problems for collaborators. Only force push if you are absolutely sure of the implications and have coordinated with your team.

Version Information

This cheatsheet is based on Git features and best practices relevant for Git version 2.45.0 (or similar stable release) as of 2025-12-23. Git maintains strong backward compatibility, so most commands will work across various versions. However, newer commands like git switch and git restore might not be available in very old Git clients.

References

1. Official Git Documentation
2. Git SCM Cheat Sheet
3. Usama.codes - Git Commands Cheat Sheet 2025
4. Codecademy - How to Use Git Rebase
5. Mergify - Essential Git Workflow Best Practices

Transparency Note

This cheatsheet was generated by an AI expert based on the provided query and search context, aiming for accuracy and relevance as of December 2025. While every effort has been made to ensure correctness, always refer to the official Git documentation for the most authoritative and up-to-date information.