Top 20 Git Commands With Examples: A Practical Workflow

These are the 20 Git commands most useful in a normal project workflow: create or clone a repository, configure Git, inspect changes, stage and commit work, review history, manage branches, synchronize with a remote, mark releases, and recover safely from mistakes.

Git works with four important pieces: the working tree contains your files, the index (or staging area) holds the exact snapshot for the next commit, HEAD identifies the current commit, and a remote such as origin points to another repository. Git itself is the version-control system; GitHub, GitLab, and similar services provide hosted remote repositories and collaboration features. See the official Git reference for the complete command documentation.

Git commands at a glance

The examples below are templates. Replace values such as <url>, <branch>, <file>, and <commit> with values from your repository.

Command	Purpose	Example	Important caution
git init	Create a local repository	git init	Does not create a remote or commit files.
git clone	Copy an existing repository	git clone <url>	Use this instead of init when a remote repository already exists.
git config	Set Git options and identity	git config --global user.name "Your Name"	--global affects your user account; without it, settings are repository-local.
git status	Inspect repository state	git status	Run it before and after important operations.
git add	Stage content for the next commit	git add <file>	Review broad staging such as git add ..
git diff	Compare file versions	git diff --cached	Plain diff and diff --cached show different changes.
git commit	Record the staged snapshot	git commit -m "Describe the change"	-a does not include new untracked files.
git log	Inspect commit history	git log --oneline --graph --decorate --all	Use path filters to investigate a particular file.
git branch	List, create, or delete branches	git branch <branch>	Creating a branch does not switch to it.
git switch	Change or create-and-change branches	git switch -c <branch>	Use it for clarity; older documentation may use checkout.
git merge	Combine histories	git merge <branch>	Resolve conflicts before completing the merge.
git rebase	Replay commits on a new base	git rebase main	Rewrites commit ancestry; be careful with shared commits.
git stash	Temporarily shelve unfinished work	git stash push -m "work in progress"	A stash is not a durable backup or substitute for a commit.
git restore	Restore file contents or unstage files	git restore <file>	Can discard uncommitted edits.
git reset	Move HEAD, the index, or the working tree	git reset HEAD~1	--hard can destroy local work and move branch history.
git revert	Undo a commit with a new commit	git revert <commit>	Usually the safer undo method for already-published history.
git fetch	Download remote updates without integrating them	git fetch origin	Fetching does not change your current branch files.
git pull	Fetch and integrate remote updates	git pull origin main	Integration can produce conflicts; preserve local work first.
git push	Publish local commits or branches	git push -u origin <branch>	Avoid routine force-pushing shared branches.
git tag	Mark an important revision	git tag -a v1.0.0 -m "Release 1.0.0"	Local tags are not automatically sent to a remote.

1. git init: create a repository

Use git init when you are starting version control for a project that exists only on your computer. It creates the repository metadata in the current directory, but it does not create a hosted repository, add a remote, or commit existing files.

mkdir my-project
cd my-project
git init

After initialization, run git status, create or copy your project files, then stage and commit them. Running git init again in an existing repository generally reinitializes it rather than creating a second independent history, but it is still wise to confirm your current directory before using it.

2. git clone: copy an existing repository

When a repository already exists on a hosting service or another server, use clone rather than init.

git clone https://github.com/USERNAME/REPOSITORY.git
cd REPOSITORY

Cloning creates a local directory, initializes its Git repository, records the source as the origin remote, downloads the repository’s objects and references, and checks out the remote’s default branch. GitHub describes this remote-to-local workflow in its documentation on getting changes from a remote repository.

3. git config: configure Git

Git uses configuration values for your commit identity and behavior. A common first-time setup is:

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

--global applies to your user account. Omit it to configure only the current repository:

git config user.email "work@example.com"

To inspect configuration, use:

git config --list

Recent Git documentation also describes explicit operations such as list, get, set, unset, rename-section, and edit. Available syntax can depend on your installed Git version, so git config --help is the authoritative reference for your environment. You can check that environment with git --version without assuming a particular release.

4. git status: see what is happening

git status compares the working tree, staging area, and HEAD. It tells you which files are modified, which changes are staged, which files are untracked, and which branch you are on.

git status
git status --short --branch

The compact form is useful during everyday work. --porcelain produces stable machine-readable output intended for scripts:

git status --porcelain

Make git status a habit before staging, committing, merging, rebasing, pulling, or using a potentially destructive command.

5. git add: stage the next snapshot

git add copies selected file content into the index, also called the staging area. The next commit records the staged snapshot—not every change currently in your working directory.

git add README.md
git add src/
git add .

git add . stages broadly, so verify the result with git status and git diff --cached. To select only portions of a file, use interactive staging:

git add -p

This lets you separate unrelated edits into separate commits, which makes review and later troubleshooting easier.

6. git diff: review changes

The most important distinction is whether you are reviewing unstaged or staged content:

git diff                 # changes not yet staged
git diff --cached        # changes staged for the next commit
git diff HEAD            # staged plus unstaged changes
git diff main..feature   # compare the tips of two branches

Before committing, inspect git diff --cached. If the output includes an unrelated change, unstage or edit it before recording the commit.

7. git commit: record a snapshot

A commit records the content currently staged in the index and adds it to the repository history.

git commit -m "Add user authentication"

For tracked files, -a stages modifications and deletions automatically before committing:

git commit -am "Fix validation bug"

However, -a does not stage new untracked files. A dependable sequence is:

git status
git diff --cached
git commit -m "Describe one coherent change"

Keep commits focused enough that another person can understand what changed and why.

8. git log: inspect history

Use git log to review commits, identify a commit to undo, or understand when a file changed.

git log --oneline --graph --decorate --all
git log --author="Name"
git log -- path/to/file

The first form gives a compact graph of local branches and remote-tracking references. The path form filters history to commits that affected a specific file. A commit identifier shown by git log can be used as the <commit> placeholder in commands such as git revert.

9. git branch: list and manage branches

A branch is a movable name pointing to a commit. Listing or creating a branch does not switch your working tree to it.

git branch
git branch feature/login
git branch -vv

-vv shows extra information such as upstream tracking where available. Delete a merged local branch with a safety check:

git branch -d feature/login

git branch -D feature/login forces deletion even when Git believes the branch may contain unmerged work. Treat -D as a deliberate recovery or cleanup operation, not the normal choice.

10. git switch: change branches

Use git switch to move to an existing branch or create and switch to a new one:

git switch main
git switch -c feature/login

switch is a focused, clearer command for branch changes. Older tutorials may use git checkout, which combines branch switching with file restoration. You may need to understand checkout in an existing project, but prefer switch for new instructional examples.

11. git merge: combine branches

The branch checked out when you run merge is the receiving branch.

git switch main
git merge feature/login

If Git reports conflicts, open each affected file, remove or revise the conflict markers, and choose the correct final content. Then stage the resolved files and complete the merge:

git add <resolved-file>
git commit

If the merge is still in progress and you want to return to the pre-merge state:

git merge --abort

12. git rebase: replay commits on a new base

Rebasing reapplies a branch’s commits on top of another branch’s current tip. It can produce a more linear history:

git switch feature/login
git rebase main

Because rebasing creates new commit ancestry, it rewrites history. Avoid rebasing commits that have already been shared when doing so would force collaborators to reconcile rewritten commits. During a conflict, resolve the file, stage it, and continue:

git add <resolved-file>
git rebase --continue

To cancel the operation:

git rebase --abort

13. git stash: temporarily shelve unfinished work

Stashing saves changes from a dirty working directory and gives you a clean working tree, which can help when you must change tasks or branches without making an unfinished commit.

git stash push -m "work in progress"
git stash list
git stash pop

git stash pop reapplies the selected stash and removes the stash entry if the operation succeeds. To reapply it while retaining the entry:

git stash apply

A stash is not a durable backup. For work that matters, a properly described commit on an appropriate private branch is usually easier to preserve and recover.

14. git restore: restore file contents or unstage

git restore focuses on file contents and does not move the current branch tip.

git restore README.md                 # discard unstaged edits to this file
git restore --staged README.md        # unstage it, keeping working-tree edits
git restore --source=HEAD~1 -- README.md

The first example can permanently discard uncommitted edits to README.md. Inspect with git status or git diff first, and do not use it as a casual undo button. The second example is safer when your goal is only to remove a file from the next commit while preserving its contents.

15. git reset: move history or reset the index

reset can move HEAD, change the staging area, and—depending on its mode—change the working tree.

git reset HEAD~1          # move the branch back; keep changes unstaged
git reset --soft HEAD~1   # move the branch back; keep changes staged
git reset --hard HEAD~1   # move the branch and working tree

The first two forms can be useful for revising a local, unpublished commit. git reset --hard is destructive: it can discard uncommitted changes and moves the branch tip. Confirm the target with git log, check git status, and preserve important work before using it. Do not present it as a routine undo command.

16. git revert: undo a published commit safely

git revert creates a new commit that reverses the changes introduced by an existing commit:

git revert <commit>

Because it preserves the existing history and records the reversal, revert is generally the safer choice for a commit already pushed to a shared branch. Follow the project’s review and branch-protection rules. If the reversal conflicts with later work, resolve the files, stage them, and complete the revert as Git instructs.

Reset vs. restore vs. revert

Command	What it changes	Typical use	History effect
git restore	Working-tree files, or the index with --staged	Discard local file edits or unstage a file	Does not move the branch tip
git reset	HEAD, index, and optionally working tree	Rework local commits or unstage changes	Can move the branch tip and rewrite local history
git revert	Creates inverse changes in a new commit	Undo a commit that may already be shared	Preserves the existing commits

If the change is already public, start by considering git revert. If you are only trying to unstage a file, use git restore --staged. If you are considering reset --hard, stop and verify that the work you would remove is not needed.

17. git fetch: download remote updates without integrating

git fetch downloads objects and references from a remote and updates remote-tracking references. It does not merge those changes into your current local branch.

git fetch origin
git log --oneline HEAD..origin/main

This is the cautious way to inspect what is available remotely before choosing whether to merge or rebase. The HEAD..origin/main range shows commits reachable from origin/main that are not reachable from your current HEAD. GitHub explains the difference between fetching remote information and pulling it into the current work in its remote repository guide.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

18. git pull: fetch and integrate

git pull fetches from a remote and integrates the result into the current branch. In the common workflow, that means fetch followed by merge, although configuration and options can select a different integration policy.

git pull origin main
git pull --rebase origin main

Before pulling, commit, stash, or otherwise safely preserve local work. A pull can produce conflicts. If your team prefers a particular policy, make that policy explicit rather than assuming every git pull behaves identically.

19. git push: publish local work

push updates references on a remote and transfers the objects needed by that remote.

git push origin main
git push -u origin feature/login

-u establishes upstream tracking for a new branch, so later plain git push and git pull commands can usually infer the remote branch.

Avoid making git push --force part of a normal workflow: it can overwrite remote history. If force-pushing is genuinely required by your team’s workflow, investigate whether --force-with-lease is appropriate and coordinate with anyone using the branch.

20. git tag: mark releases and other milestones

Tags give important revisions stable names, commonly for releases.

git tag                              # list local tags
git tag v1.0.0                       # create a lightweight tag
git tag -a v1.0.0 -m "Release 1.0.0"  # create an annotated tag
git push origin v1.0.0               # publish one tag

A tag created locally is not automatically published. To publish all local tags, use this only when that is the intended workflow:

git push origin --tags

Use a consistent naming policy and confirm the tag points to the intended commit before publishing it.

A practical beginner Git workflow

For an existing remote repository, this is a compact feature-branch workflow:

git clone <url>
cd <repo>
git status
git switch -c feature/example
# edit files
git diff
git add <file>
git diff --cached
git commit -m "Describe the change"
git push -u origin feature/example

After the branch is pushed, open the project’s normal review or merge process. If you are starting locally instead, replace the clone step with mkdir, cd, and git init, then configure your identity, add files, and make the first commit.

Recovery and safety checklist

• Before staging: run git status and inspect changes with git diff.
• Before committing: run git diff --cached so you know exactly what the commit contains.
• Before pulling, merging, or rebasing: commit or safely preserve local work.
• When conflicts occur: resolve the files, run git add <resolved-file>, then use the operation’s continuation command—or abort with git merge --abort or git rebase --abort when appropriate.
• For a shared commit that needs undoing: prefer git revert <commit> over rewriting published history.
• For uncommitted edits: treat git restore and git reset --hard as potentially irreversible. Inspect first and preserve important work.
• For untracked files: remember that git clean is outside this 20-command list but can remove untracked files. Preview with git clean -n; the official manual notes that actual cleaning normally requires -f. Never use it casually.
• For force-pushes: avoid --force on shared branches; coordinate with collaborators and consider --force-with-lease only when necessary.

For canonical syntax and the full set of options, use the official Git command reference. The online edition of Pro Git is free, while readers who prefer paper can look for a print copy of Pro Git as an optional Git command-line reference book.

Frequently Asked Questions

Should I use git init or git clone?

Use git init for a project that exists locally without a repository. Use git clone when a remote repository already exists and you want a local copy with its history and remote configuration.

What is the safest way to undo a commit?

For a commit already shared with others, use git revert <commit>; it creates a new inverse commit. For a private local commit, git reset may be appropriate, but its modes have different effects and --hard can discard work.

Why does git commit -am not include my new file?

The -a option automatically stages modifications and deletions of files Git already tracks. It does not stage untracked files. Run git add <new-file> first.

Does git fetch change my current files?

Normally, no. git fetch downloads remote objects and updates remote-tracking references without integrating them into your current branch. git pull fetches and then integrates according to the selected merge or rebase policy.

The Bottom Line

The safest everyday pattern is status, diff, add, diff --cached, commit, then push. Use fetch when you want to inspect remote work before integrating it, use revert for undoing shared history, and pause before commands that can discard files or rewrite commits.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.