Git Cheat Sheet for Everyday Commands: Clone, Branch, Commit, Merge, and Undo

Overview

Git is easiest to learn when you stop thinking of it as a list of commands and start thinking of it as a small daily workflow. You get a copy of a repository, create or switch to a branch, make changes, review them, commit them in logical steps, sync with the remote repository, and then merge or open a pull request. Most frustration comes from skipping one of those stages or using an undo command without checking what state the repository is currently in.

This guide is written as a beginner friendly tutorial, but it is also useful as a quick reference for experienced developers who want clear instructions instead of broad theory. The command examples assume a standard command-line setup, but the workflow maps cleanly to desktop clients and IDE integrations too.

Before using the commands below, it helps to understand four terms:

• Repository: the project tracked by Git.
• Working tree: the files you are actively editing.
• Staging area: the set of changes prepared for the next commit.
• Remote: the hosted copy of the repository, often called origin.

If you are setting up a project that also involves deployment or website changes, version control works best alongside a safe testing workflow. For WordPress or web projects, a staging environment can prevent risky direct edits; see How to Create a Staging Site for WordPress and Test Changes Safely.

Step-by-step workflow

Use this section as the main Git cheat sheet for everyday commands. The sequence matters. If you follow it consistently, Git becomes much more predictable.

1. Clone a repository

Use git clone when you need a local copy of an existing remote repository.

git clone https://example.com/project.git
cd project

This creates a new folder, downloads the repository history, and sets the remote named origin. If you already have the repository locally, do not clone it again just to get updates. Use git pull instead.

2. Check the current state first

Before making changes or trying to fix a problem, start with status.

git status

This is one of the most useful common Git commands because it tells you:

• which branch you are on
• whether files are modified, staged, or untracked
• whether your branch is ahead or behind the remote

If Git feels confusing, git status is usually the fastest way to reorient yourself.

3. Create and switch to a branch

For feature work, bug fixes, or experiments, use a branch instead of committing directly on a shared main branch.

git switch -c fix-header-layout

Older tutorials may use:

git checkout -b fix-header-layout

Both create and switch to a new branch. The newer git switch syntax is easier to read for branch operations.

To list branches:

git branch

To switch to an existing branch:

git switch main

4. Review what changed

Before staging anything, inspect your edits.

git diff

This shows unstaged changes. To see staged changes:

git diff --staged

Reviewing diffs before a commit helps catch accidental edits, debug code left in place, or formatting noise.

5. Stage files deliberately

Add the files you want in the next commit.

git add file-name.js

To stage all modified and new files in the current directory tree:

git add .

Be careful with git add . in large repositories. It is fast, but it can stage more than you intended. For cleaner history, stage only the files related to one logical change.

6. Commit with a clear message

A commit should explain what changed and why, not just mark a save point.

git commit -m "Fix mobile menu overlap on tablet breakpoint"

Useful commit messages are specific enough that someone scanning history can understand the change without opening every diff. A practical pattern is:

• What changed: Fix, add, remove, refactor, update
• Where: menu, checkout form, API client, config
• Why if needed: avoid duplicate validation, support new route, correct deployment path

7. Pull remote changes before pushing

If other people are working in the same repository, update your branch before pushing to avoid preventable conflicts.

git pull origin main

If you are on a feature branch and need the latest changes from main, switch to your branch and merge or rebase the updated main branch into it, depending on your team workflow. For many teams, merge is the simpler and safer default for beginners.

8. Push your branch

Send your commits to the remote repository.

git push -u origin fix-header-layout

The -u flag sets the upstream branch, so future pushes can usually be shortened to:

git push

Likewise, later pulls can often be just:

git pull

9. Merge a branch

When the work on a branch is complete and reviewed, merge it into the target branch.

git switch main
git pull origin main
git merge fix-header-layout

This basic Git branch merge guide keeps the sequence clear:

1. switch to the branch that will receive the changes
2. make sure it is up to date
3. merge the feature branch into it

If there are no conflicts, Git creates the merge cleanly. If there are conflicts, Git will mark the affected files for manual review.

10. Resolve merge conflicts carefully

When two branches edit the same lines or nearby sections, Git may not know which version to keep. Open the conflicted files and look for markers like these:

<<<<<<< HEAD
current branch content
=======
incoming branch content
>>>>>>> fix-header-layout

Edit the file to the correct final version, remove the markers, then stage and commit the resolution:

git add conflicted-file.js
git commit

Do not rush conflict resolution. If the code affects production behavior, test the merged result. For web projects, browser inspection helps verify whether a merge introduced front-end errors; see How to Use Browser DevTools to Troubleshoot CSS, JavaScript, and Network Errors.

11. Inspect history

When you need to understand what happened, use log commands.

git log --oneline --graph --decorate --all

This compact view is excellent for tracing branch history, merge points, and recent commits. If a deployment or release broke something, history is often the fastest place to start.

12. Undo safely

The phrase “Git undo command” covers several different situations. The right command depends on what exactly you want to undo.

Undo unstaged file changes

git restore file-name.js

This discards working tree edits for that file and returns it to the last committed version. Use it only if you are sure you do not need the local changes.

Unstage a file

git restore --staged file-name.js

This removes the file from the staging area but keeps your edits in the working tree.

Amend the last commit

git commit --amend

Use this if you forgot a file or want to revise the last commit message. Avoid amending commits that are already shared unless your team is comfortable rewriting branch history.

Revert a commit without rewriting history

git revert COMMIT_HASH

This is usually the safest way to undo a commit that has already been pushed. It creates a new commit that reverses the earlier change.

Reset local history

git reset --soft HEAD~1

This moves the branch pointer back one commit but keeps changes staged.

git reset --mixed HEAD~1

This moves back one commit and keeps changes unstaged.

git reset --hard HEAD~1

This removes the commit and discards local changes. It is powerful and risky. Use it only when you fully understand the consequences.

A good rule: if the commit is already on a shared remote branch, prefer git revert. If the mistake is still local and unshared, git reset may be appropriate.

Tools and handoffs

Git works best when you are clear about what Git handles directly and what belongs to your editor, hosting platform, CI system, or deployment workflow.

Core tools in a simple Git workflow

• Terminal: fastest for clear, repeatable Git commands.
• Code editor or IDE: useful for viewing diffs, staging chunks, and resolving conflicts.
• Remote host: where branches, pull requests, and team collaboration happen.
• CI or deployment system: where tests, builds, and releases run after pushes or merges.

Recommended handoff points

A practical handoff model looks like this:

1. Edit code locally.
2. Use git status and git diff before staging.
3. Commit locally in small, meaningful units.
4. Push the branch to the remote.
5. Open a pull request or begin code review.
6. Merge only after review and checks pass.
7. Deploy from a known branch, tag, or release process.

This matters especially for websites and production systems. Git tracks code and content changes, but it does not replace environment checks, DNS verification, or browser troubleshooting. If your repository changes are tied to site launches or migrations, related operational guides may help, such as How to Migrate a WordPress Site to a New Host Without Downtime or How to Fix DNS_PROBE_FINISHED_NXDOMAIN: Domain and Browser Troubleshooting Steps.

Useful helper commands to keep nearby

git remote -v
git fetch
git branch -a
git show COMMIT_HASH
git stash
git stash pop

These are not always part of the core loop, but they are helpful when you need to inspect remotes, retrieve updates without merging, view all branches, inspect a specific commit, or temporarily set work aside.

git stash is particularly useful when you need to switch tasks quickly without making a messy half-finished commit. Still, do not treat stash as permanent storage. Return to it, apply it, and clean it up.

Quality checks

If you want fewer Git mistakes, build a short review checklist into your routine. Most problems are visible before they become history problems.

Before every commit

• Run git status.
• Review git diff.
• Stage only files related to one change.
• Write a specific commit message.

Before every push

• Confirm you are on the correct branch.
• Pull or fetch recent remote changes if the branch is shared.
• Run tests, linters, or build steps if your project uses them.
• Check for debug output, commented code, or secrets.

Before every merge

• Make sure the target branch is up to date.
• Read the diff one more time.
• Resolve conflicts intentionally, not mechanically.
• Validate the application after merging.

Common errors to fix early

Committing directly to main: move back to a branch-based workflow for anything beyond a trivial personal change.

Large mixed commits: break unrelated edits into separate commits so rollback and review stay manageable.

Using reset on shared history: if others may have pulled the commit, use revert instead.

Pushing without pulling: this often creates avoidable conflicts, especially on active team branches.

Skipping diff review: many small Git accidents come from staging generated files, local configuration, or unfinished edits.

For web applications, your quality check should extend beyond Git itself. If a merged change affects performance or page behavior, you may also want a repeatable testing checklist. Related reading: How to Speed Up a WordPress Site: Performance Checklist You Can Reuse.

When to revisit

Return to this cheat sheet whenever your daily workflow changes, your team adopts a new branching model, or Git introduces updated command patterns. The basics stay stable, but the safest way to clone, branch, commit, merge, and undo can shift slightly as tooling improves and teams standardize around different conventions.

Revisit your Git process in these situations:

• you start working with a new team or repository
• your organization changes branch naming or review rules
• you move from solo work to collaborative pull-request workflows
• you begin using CI checks, protected branches, or deployment gates
• you notice repeated merge conflicts or confusing history
• you rely on older commands and want to refresh your habits

A practical maintenance habit is to keep a short personal Git manual with the exact commands your environment uses most often. Include your standard branch naming pattern, your preferred pull strategy, your test commands, and your safest undo options. That turns a general Git cheat sheet into a repeatable team workflow.

If you want one action to take right now, use this small checklist:

1. Open a test repository or safe branch.
2. Practice git clone, git switch -c, git add, git commit, git push, and git merge.
3. Then deliberately practice git restore, git revert, and git reset --soft so you understand the differences before a real mistake happens.
4. Save the command set you use most into your notes or editor snippets.

The goal is not to memorize every Git command. It is to have a clear, reusable process for everyday work and a safe response when something goes wrong. That is what makes a Git reference worth revisiting.