The Ultimate Git Commands Cheat Sheet for Beginners (With Examples)

If you're learning to code, chances are someone has already told you: "Learn Git." And they're right. Git is the single most important tool for managing code changes, collaborating with other developers, and keeping your projects safe from disaster.

 

But Git can feel intimidating at first. The terminal, the strange vocabulary (commits, branches, rebasing), and the sheer number of commands can overwhelm beginners.

 

This guide breaks it all down. You'll learn what Git is, why it matters, and how to use the most essential Git commands with real examples. By the end, you'll have a working mental model of Git and a cheat sheet you can return to any time you need a quick reference.

 

Whether you're a computer science student, a junior developer, or someone moving from a GUI-based Git client to the command line, this Git tutorial is designed for you.

 

What is Git?

 

Git is a distributed version control system. In plain English, that means Git tracks every change made to your files over time, and it lets you (and your team) go back to any previous version whenever you need to.

 

"Distributed" means every developer has a full copy of the project's history on their own machine, not just on a central server. This makes Git fast, resilient, and ideal for collaboration — even offline.

 

Git was created by Linus Torvalds in 2005 to manage the Linux kernel's source code. Today, it's the backbone of almost every modern software project, and platforms like GitHub, GitLab, and Bitbucket are built around it.

 

A few core concepts you'll see throughout this article:

• Repository (repo) — a project folder tracked by Git.
• Commit — a saved snapshot of your project at a point in time.
• Branch — an independent line of development.
• Remote — a version of your repository hosted elsewhere (like GitHub).
• Working directory — the files you're currently editing.
• Staging area (index) — a holding zone for changes you're about to commit.

 

Why Use Git?

 

Understanding why Git matters makes the commands easier to remember. Here's what Git gives you:

• History and accountability. Every change is recorded, along with who made it and why.
• Safety net. You can undo mistakes, recover deleted code, or roll back to a working version.
• Collaboration. Multiple developers can work on the same project without overwriting each other's work.
• Branching and experimentation. You can try new features in isolation without breaking the main codebase.
• Industry standard. Nearly every tech company and open-source project uses Git, making it a non-negotiable skill.

 

In short, version control with Git isn't optional in professional software development — it's foundational.

 

Installing Git

Before running any Git commands, you need Git installed on your machine.

Windows:

# Download and run the installer from:
# https://git-scm.com/download/win

 

macOS (using Homebrew):

brew install git

 

Linux (Debian/Ubuntu):

sudo apt update
sudo apt install git

 

Verify installation:

git --version

Expected output (version numbers may vary):

git version 2.44.0

 

Git Workflow Overview

 

Before diving into individual commands, it helps to see the big picture. A typical Git workflow looks like this:

1. Initialize or clone a repository.
2. Make changes to files in your working directory.
3. Stage the changes you want to save (git add).
4. Commit the staged changes with a message (git commit).
5. Push the commits to a remote repository (git push).
6. Pull updates from teammates (git pull).
7. Branch and merge to work on features safely.

 

Keep this cycle in mind — almost every Git command fits somewhere in this loop.

 

Essential Git Commands

 

Below is a detailed breakdown of the most important Git commands, with syntax, examples, and practical tips.

 

git config

 

Purpose: Sets configuration values for Git, such as your username, email, and default editor. This is usually the first command you run after installing Git.

 

Syntax:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

 

Parameters:

• --global — applies the setting to all repositories on your machine.
• --local — applies only to the current repository (default if --global is omitted).
• user.name / user.email — identifies you in commit history.

 

Example:

git config --global user.name "Jane Doe"
git config --global user.email "jane@example.com"

 

Check your settings:

git config --list

 

Common use cases: Setting identity, default branch name, default editor, and aliases.

 

Tip: Use --global once per machine so you don't have to repeat it for every repository.

 

 git init

 

Purpose: Creates a new, empty Git repository in the current folder.

 

Syntax:

git init

 

Example:

mkdir my-project
cd my-project
git init

 

Expected output:

Initialized empty Git repository in /path/to/my-project/.git/

 

Common use cases: Starting a brand-new project that isn't tracked by Git yet.

 

Caution: Running git init inside an existing Git repository can create nested repositories — avoid it unless intentional..

 

 git clone

 

Purpose: Downloads (copies) an existing remote repository, including its full history, to your local machine.

 

Syntax:

git clone <repository-url>

 

Example:

git clone https://github.com/example-user/example-repo.git

 

Expected output:

Cloning into 'example-repo'...
remote: Enumerating objects: 120, done.
Receiving objects: 100% (120/120), done.

 

Common use cases: Getting a copy of a project to contribute to, or setting up a new machine.

 

Tip: Clone into a specific folder name with git clone <url> <folder-name>.

 

git status

 

Purpose: Shows the current state of your working directory and staging area — which files are modified, staged, or untracked.

 

Syntax:

git status

 

Example output:

On branch main
Changes not staged for commit:
  modified:   index.html

Untracked files:
  new-file.txt

 

Common use cases: Checking what's changed before staging or committing. This is one of the most frequently used Git commands — run it often.

 

Tip: Use git status -s for a short, compact version of the output.

 

git add

 

Purpose: Moves changes from your working directory into the staging area, preparing them for a commit.

 

Syntax:

git add <file>
git add .

 

Parameters:

• <file> — a specific file to stage.
• . — stages all changes in the current directory.

 

Example:

git add index.html
git add .

 

Common use cases: Selecting exactly which changes should be included in the next commit.

 

Caution: git add . stages everything, including files you might not intend to commit. Review with git status first.

 

git commit

 

Purpose: Saves a snapshot of staged changes into the repository's history.

 

Syntax:

git commit -m "Your commit message"

 

Parameters:

• -m — allows you to write the commit message inline.
• -a — automatically stages all tracked, modified files before committing.

 

Example:

git commit -m "Add homepage layout"

 

Expected output:

[main 3f2a1b9] Add homepage layout
 1 file changed, 12 insertions(+)

 

Common use cases: Saving a logical, complete unit of work.

 

Tip: Write clear, descriptive commit messages in the imperative mood (e.g., "Fix login bug," not "Fixed" or "Fixes").

git log

 

Purpose: Displays the commit history of the repository.

 

Syntax:

git log
git log --oneline

 

Example output:

commit 3f2a1b9c8e...
Author: Jane Doe <jane@example.com>
Date:   Mon Jul 20 10:15:00 2026

    Add homepage layout

 

Common use cases: Reviewing project history, finding a specific commit, auditing changes.

 

Tip: git log --oneline --graph --all gives a compact, visual branch history — extremely useful for understanding project flow.

 

git diff

 

Purpose: Shows the differences between your working directory, staging area, and commits.

 

Syntax:

git diff
git diff --staged

 

Example:

git diff index.html

 

Common use cases: Reviewing exactly what changed before staging or committing.

 

Tip: Use git diff --staged to see what will be included in your next commit.

 

git branch

 

Purpose: Lists, creates, or deletes branches.

 

Syntax:

git branch
git branch <branch-name>
git branch -d <branch-name>

 

Example:

git branch feature-login

 

Expected output (listing branches):

* main
  feature-login

 

Common use cases: Creating isolated environments for new features or bug fixes.

 

Tip: The * marks your currently active branch.

 

git checkout

 

Purpose: Switches between branches or restores files. In older Git workflows, this was also used to create branches.

 

Syntax:

git checkout <branch-name>
git checkout -b <new-branch-name>

 

Example:

git checkout -b feature-login

 

Common use cases: Switching context between features, creating and switching to a new branch in one step.

 

Caution: git checkout is a multi-purpose command that can also discard file changes — use carefully. Modern Git recommends git switch and git restore for clarity.

 

git switch

 

Purpose: A newer, more intuitive command dedicated solely to switching branches (introduced to simplify git checkout's many roles).

 

Syntax:

git switch <branch-name>
git switch -c <new-branch-name>

 

Example:

git switch -c feature-signup

 

Common use cases: Safer, clearer branch switching without risk of accidentally discarding files.

 

Tip: Prefer git switch over git checkout for branch operations in modern workflows.

 

git merge

 

Purpose: Combines changes from one branch into another.

 

Syntax:

git merge <branch-name>

 

Example:

git switch main
git merge feature-login

 

Expected output:

Updating 3f2a1b9..7c4d2e1
Fast-forward
 login.html | 20 ++++++++++++++++++

 

Common use cases: Integrating completed feature branches back into the main branch.

 

Tip: If a merge conflict occurs, Git will mark the conflicting sections in the file — resolve them manually, then run git add and git commit.

 

git rebase

 

Purpose: Reapplies commits from one branch on top of another, creating a cleaner, linear history.

 

Syntax:

git rebase <branch-name>

 

Example:

git switch feature-login
git rebase main

 

Common use cases: Keeping a feature branch up to date with main without creating extra merge commits.

 

Caution: Never rebase commits that have already been pushed and shared with others — it rewrites history and can cause serious problems for collaborators.

 

git stash

 

Purpose: Temporarily saves uncommitted changes so you can switch context without committing incomplete work.

 

Syntax:

git stash
git stash pop

 

Example:

git stash
git switch main
# do something else
git switch feature-login
git stash pop

 

Common use cases: Quickly switching branches without losing in-progress work.

 

Tip: Use git stash list to see all stashed changes, and git stash drop to discard one.

 

git remote

 

Purpose: Manages connections to remote repositories.

 

Syntax:

git remote add <name> <url>
git remote -v

 

Example:

git remote add origin https://github.com/example-user/example-repo.git

 

Common use cases: Linking a local repository to GitHub, GitLab, or another remote host.

 

Tip: origin is the conventional name for your primary remote, but you can name it anything.

 

git fetch

 

Purpose: Downloads new data (commits, branches) from a remote repository without merging it into your local branches.

 

Syntax:

git fetch <remote>

 

Example:

git fetch origin

 

Common use cases: Checking what's new on the remote before deciding to merge or pull.

 

Tip: git fetch is a safe way to preview updates without altering your working files.

 

git pull

 

Purpose: Fetches changes from a remote repository and immediately merges them into your current branch.

 

Syntax:

git pull <remote> <branch>

 

Example:

git pull origin main

 

Common use cases: Syncing your local branch with the latest team changes.

 

Caution: git pull = git fetch + git merge. If conflicts exist, you'll need to resolve them before continuing.

 

git push

 

Purpose: Uploads your local commits to a remote repository.

 

Syntax:

git push <remote> <branch>

 

Example:

git push origin main

 

Common use cases: Sharing your committed work with your team or publishing it online.

 

Tip: Use git push -u origin <branch> the first time you push a new branch to set up tracking, so future pushes only need git push.

 

git tag

 

Purpose: Marks specific commits, typically used for release versions (e.g., v1.0.0).

 

Syntax:

git tag <tag-name>
git push origin <tag-name>

 

Example:

git tag v1.0.0
git push origin v1.0.0

 

Common use cases: Marking release points, creating changelogs, deployment tracking.

 

Tip: Use annotated tags (git tag -a v1.0.0 -m "Release 1.0.0") for more metadata, like release notes.

 

git reset

 

Purpose: Moves the current branch pointer to a different commit, optionally changing staged and working directory files.

 

Syntax:

git reset <mode> <commit>

 

Parameters:

• --soft — keeps changes staged.
• --mixed (default) — unstages changes but keeps them in the working directory.
• --hard — discards all changes completely.

 

Example:

git reset --hard HEAD~1

 

Common use cases: Undoing commits, unstaging files, correcting mistakes.

 

Caution: git reset --hard permanently discards changes. Double-check before using it.

 

git revert

 

Purpose: Creates a new commit that undoes the changes from a previous commit, without altering history.

 

Syntax:

git revert <commit-hash>

 

Example:

git revert 3f2a1b9

 

Common use cases: Safely undoing changes in a shared branch without rewriting history.

 

Tip: git revert is safer than git reset for shared/public branches because it preserves history.

 

git rm

 

Purpose: Removes files from both the working directory and Git tracking.

 

Syntax:

git rm <file>

 

Example:

git rm old-file.txt
git commit -m "Remove unused file"

 

Common use cases: Deleting files that should no longer be tracked.

 

Tip: Use git rm --cached <file> to stop tracking a file without deleting it locally.

 

git mv

 

Purpose: Renames or moves a file while keeping Git's tracking intact.

 

Syntax:

git mv <old-name> <new-name>

 

Example:

git mv index.html home.html
git commit -m "Rename index.html to home.html"

 

Common use cases: Reorganizing project structure without losing file history.

 

Common Git Workflow Example (Step-by-Step)

 

Here's a realistic, end-to-end Git workflow you'll use constantly:

# 1. Clone the project
git clone https://github.com/example-user/example-repo.git
cd example-repo

# 2. Create a new branch for your feature
git switch -c feature-user-profile

# 3. Make changes, then check status
git status

# 4. Stage your changes
git add .

# 5. Commit with a clear message
git commit -m "Add user profile page"

# 6. Keep your branch updated with main
git fetch origin
git rebase origin/main

# 7. Push your branch to the remote
git push -u origin feature-user-profile 

# 8. Open a pull request on GitHub/GitLab, get it reviewed, then merge 

# 9. Switch back to main and pull the merged changes
git switch main
git pull origin main 

# 10. Delete the now-merged feature branch
git branch -d feature-user-profile

 

This cycle — branch, code, commit, push, merge — is the daily rhythm of professional Git usage.

 

Git Best Practices

• Commit often, in small chunks. Small commits are easier to review, debug, and revert.
• Write meaningful commit messages. Describe what changed and why, not just "fix stuff."
• Use branches for every feature or fix. Never work directly on main in a team setting.
• Pull before you push. Reduces merge conflicts and keeps your branch current.
• Review changes before committing. Use git diff and git status as a habit.
• Avoid committing sensitive data. Use a .gitignore file to exclude secrets, credentials, and build artifacts.
• Don't rewrite shared history. Avoid rebase or reset --hard on branches others depend on.
• Tag releases. Makes it easy to track versions and roll back if needed.

 

Common Errors and How to Fix Them

 

1. "fatal: not a git repository" Cause: You're running a Git command outside a Git-tracked folder. Fix: cd into the correct project folder, or run git init.

2. Merge conflicts Cause: Two branches changed the same lines of a file. Fix: Open the conflicting file, resolve the marked sections (<<<<<<<, =======, >>>>>>>), then:

git add <file>
git commit

3. "Updates were rejected because the remote contains work..." Cause: The remote has commits you don't have locally. Fix:

git pull origin main

4. Accidentally committed to the wrong branch Fix: Use git reset --soft HEAD~1 to undo the commit (keeping changes), then switch to the correct branch and recommit.

5. Detached HEAD state Cause: You checked out a specific commit instead of a branch. Fix:

git switch -c new-branch-name

 

Git Command Cheat Sheet

 

Command	Purpose
git config	Set username, email, and preferences
git init	Create a new repository
git clone	Copy an existing remote repository
git status	Show current changes and state
git add	Stage changes for commit
git commit	Save staged changes as a snapshot
git log	View commit history
git diff	Show differences between changes
git branch	List, create, or delete branches
git checkout	Switch branches or restore files
git switch	Switch branches (modern alternative)
git merge	Combine branches
git rebase	Reapply commits on a new base
git stash	Temporarily save uncommitted changes
git remote	Manage remote repository links
git fetch	Download remote changes without merging
git pull	Fetch and merge remote changes
git push	Upload local commits to remote
git tag	Mark specific commits (e.g., releases)
git reset	Undo commits or unstage changes
git revert	Undo a commit with a new commit
git rm	Remove tracked files
git mv	Rename or move tracked files

 

Frequently Asked Questions (FAQ)

 

Q: What's the difference between git fetch and git pull? 

A: git fetch downloads updates without merging them into your branch. git pull fetches and merges automatically.

 

Q: What's the difference between git merge and git rebase? 

A: git merge creates a merge commit that combines two histories. git rebase rewrites commits onto a new base, producing a linear history — but it should never be used on shared branches.

 

Q: Do I need GitHub to use Git? 

A: No. Git works entirely locally. GitHub, GitLab, and Bitbucket are hosting platforms that add collaboration features on top of Git.

 

Q: How do I undo my last commit? 

A: Use git reset --soft HEAD~1 to undo the commit but keep your changes, or git revert HEAD to undo it with a new commit (safer for shared branches).

 

Q: What is a .gitignore file? 

A: A file that tells Git which files or folders to exclude from version control — commonly used for dependencies, build files, and secrets.

 

Q: Is Git the same as GitHub? 

A: No. Git is the version control tool; GitHub is a cloud platform for hosting Git repositories and enabling collaboration.

 

Conclusion

 

Git might seem complex at first, but its core loop — stage, commit, push, pull, branch, merge — becomes second nature with practice. Mastering these essential Git commands gives you the confidence to collaborate on real-world projects, recover from mistakes, and work efficiently from the command line.

Bookmark the cheat sheet above, practice the workflow example on a test project, and soon Git will feel less like a chore and more like a superpower in your developer toolkit.