Git Commands Cheat Sheet for Daily Development Workflows

Overview

Git is easiest to use when you stop thinking in terms of memorizing every command and start thinking in terms of small, repeatable tasks. Most developers do the same things every day: check status, create a branch, stage changes, commit, pull updates, push work, and occasionally undo something. A practical git commands cheat sheet should support those habits.

This reference focuses on everyday workflows rather than edge cases. The goal is not to cover every flag Git supports. The goal is to help you move safely through the most common development scenarios with clear command choices and a mental model that prevents avoidable mistakes.

A useful way to think about Git is through three layers:

• Working directory: your actual files on disk
• Staging area: the set of changes you plan to include in the next commit
• Repository history: the commit timeline in your local and remote repos

Many Git mistakes come from not knowing which layer a command affects. For example, git restore changes files in your working directory, git add moves changes into the staging area, and git reset often changes what is staged or where your branch points. When you know the layer, the command becomes easier to choose.

If you are building your own broader reference library, it helps to treat Git the same way you treat other developer resources: a scenario-based guide you revisit often, like a SQL joins reference or a JavaScript methods summary. For related examples of that format, see SQL Joins Explained Visually and JavaScript Array Methods Cheat Sheet.

Core daily commands at a glance

git status
git branch
git switch -c feature-name
git pull --rebase origin main
git add .
git commit -m "Describe the change"
git push -u origin feature-name
git log --oneline --graph --decorate

Those commands cover a large share of routine development work. The sections below organize them into a workflow you can follow.

Step-by-step workflow

This section gives you a practical process from starting work to shipping it. You do not need to use every command every time, but the sequence is stable enough for daily use.

1. Start by checking where you are

Before changing anything, inspect the repository state.

git status
git branch --show-current
git remote -v

Use these commands to answer three questions:

• Do I have uncommitted changes?
• Which branch am I on?
• Which remote is connected?

git status is the safest first command in almost any situation. It shows modified files, staged files, untracked files, and whether your branch is ahead or behind the remote.

2. Update your base branch before new work

Teams vary on whether the main branch is called main, master, or something else, but the idea is the same: refresh your local copy before branching.

git switch main
git pull origin main

If your team prefers a cleaner local history, use rebase:

git pull --rebase origin main

That can reduce unnecessary merge commits in local development. If you are unsure what your team expects, prefer the convention already used in the repository.

3. Create a branch for the task

Create a focused branch for one feature, bug fix, or refactor.

git switch -c fix/login-validation

Common alternatives:

git checkout -b fix/login-validation

git switch is usually easier to read for branch changes, while git checkout is older and still common in many codebases.

Branch naming works best when it is short, descriptive, and consistent. For example:

• feature/user-profile
• fix/api-timeout
• chore/update-eslint

4. Review changes as you work

Do not wait until the end of a task to inspect what changed.

git status
git diff
git diff --staged

Use git diff to review unstaged changes and git diff --staged to review exactly what is about to be committed. This habit catches accidental edits, formatting-only noise, and unrelated file changes early.

5. Stage only what belongs in the commit

The default shortcut is often:

git add .

That is useful, but not always precise. When you want more control, stage file by file:

git add src/auth.js
git add tests/auth.test.js

For partial staging, use:

git add -p

This is one of the most valuable Git workflow commands for clean history. It lets you split unrelated edits into separate commits even if you made them in the same session.

6. Commit with a clear message

Once the staged changes represent one logical unit, commit them.

git commit -m "Fix login validation for empty email"

Good commit messages help future debugging, code review, and release tracking. A simple rule works well: start with a verb and describe the change, not the time you spent on it.

Better:

• Fix null check in auth middleware
• Add profile image upload endpoint
• Refactor form state handling in settings page

Less useful:

• changes
• update
• work in progress

7. Push your branch to the remote

The first push usually sets the upstream branch:

git push -u origin fix/login-validation

After that, a plain push is often enough:

git push

This is the usual handoff point for opening a pull request or merge request.

8. Sync your branch with the latest base branch

If the base branch has moved while you are working, update your feature branch before review or merge.

Merge approach:

git switch main
git pull origin main
git switch fix/login-validation
git merge main

Rebase approach:

git switch main
git pull origin main
git switch fix/login-validation
git rebase main

Use merge when you want the integration point preserved clearly. Use rebase when you want a cleaner linear branch history. Both are valid if used consistently with team expectations.

9. Handle conflicts carefully

When Git cannot combine changes automatically, it marks conflicts in affected files. A safe resolution flow is:

git status
# edit conflicted files
# remove conflict markers after resolving
git add resolved-file.js

If you are merging:

git commit

If you are rebasing:

git rebase --continue

To stop and return to the earlier state:

git merge --abort
git rebase --abort

During conflicts, move slowly. Review each file, run tests, and avoid resolving by habit.

10. Clean up after merge

Once the branch is merged, remove stale branches locally and remotely if your team does that manually.

git branch -d fix/login-validation
git push origin --delete fix/login-validation

Then refresh your branch list:

git fetch --prune

This keeps your local repository easier to navigate.

Common git undo commands

Undo commands deserve their own place because they are where caution matters most.

Unstage a file but keep the changes:

git restore --staged file.js

Discard local changes in a file:

git restore file.js

Amend the last commit message or include staged changes:

git commit --amend

Move branch pointer back but keep changes unstaged:

git reset HEAD~1

Create a new commit that reverses an earlier commit:

git revert <commit-hash>

For shared branch history, git revert is usually safer than rewriting history with reset. In local-only work, reset can be faster.

Tools and handoffs

Git rarely operates alone. Daily development usually involves an editor, a code host, CI checks, and team review. This section helps connect command-line work to the larger workflow.

Local tools that pair well with Git

• Terminal: fastest path for most common git reference for developers
• Editor source control panel: useful for visual diffs and quick staging
• GUI clients: helpful for branch graphs, conflict resolution, and history browsing
• Hooks and linters: catch formatting or test issues before commits

The command line remains the best baseline because it transfers across editors and platforms. GUIs can be excellent on top of that, but they are easiest to use when you already understand what command they are running for you.

Typical handoffs in a team workflow

1. Developer handoff to remote repository: git push
2. Repository handoff to code review: open a pull request
3. Code review handoff to CI: tests, linting, build validation
4. Approved branch handoff to main: merge, squash, or rebase according to team convention

To make those handoffs smoother, keep changes scoped and commits readable. Small, focused branches are easier to review and less likely to conflict.

Useful inspection commands

git log --oneline --graph --decorate --all
git show <commit-hash>
git blame path/to/file

These commands are especially helpful when you are joining an existing codebase or tracing a regression. git log --graph makes branch history easier to read, while git show gives you the exact patch and metadata for one commit.

Stash for temporary context switching

Sometimes you need to pause unfinished work to fix something urgent.

git stash
git switch main
# do urgent work

Then recover the earlier changes:

git stash list
git stash pop

Stash is useful, but it is best treated as temporary storage, not a long-term workflow. If work is meaningful and coherent, a branch and a commit are often clearer.

If you like cheat sheets that connect syntax to everyday usage, you may also find value in practical references such as CSS Flexbox Cheat Sheet with Common Layout Patterns, which follows a similar scenario-first approach.

Quality checks

The best Git workflow is not just about speed. It is about reducing avoidable mistakes before they spread to teammates, CI pipelines, or production branches. These checks are simple enough to use every day.

Before committing

• Run git status and confirm only intended files changed
• Review the patch with git diff or git diff --staged
• Remove debug code, stray logs, and temporary comments
• Keep commits focused on one logical change

Before pushing

• Run tests relevant to your change
• Pull or rebase from the current base branch if needed
• Check commit messages for clarity
• Make sure secrets, environment files, or generated files are not accidentally included

Before merging

• Confirm the branch still builds cleanly
• Read the diff from the reviewer perspective
• Make sure the pull request description explains intent and risk
• Resolve conflicts locally and rerun checks

Safety notes for destructive commands

Some common git commands are powerful enough to cause confusion when used casually. Treat these carefully:

• git reset --hard: discards uncommitted changes
• git push --force: rewrites remote history
• git clean -fd: removes untracked files and directories

These are not forbidden, but they deserve confirmation before use. A good rule is simple: if the branch is shared, prefer non-destructive options unless your team explicitly coordinates history rewriting.

A compact daily checklist

1. git status
2. git switch main && git pull --rebase origin main
3. git switch -c feature/task-name
4. work, then git diff
5. git add -p
6. git commit -m "Clear message"
7. run tests
8. git push -u origin feature/task-name

That short loop is enough for most project based coding tutorials, production tasks, and personal repositories.

When to revisit

A cheat sheet stays useful when it changes with your workflow. Revisit this Git reference whenever your tools, team conventions, or project size shift enough to make your current habits feel awkward.

Update your workflow when these things change

• Your team adopts a different merge strategy: for example, moving from merge commits to rebase-and-squash
• Your editor or Git client changes: shortcuts may differ, but the underlying commands stay the same
• Your repository gets larger: partial staging, cleaner branches, and more careful history inspection become more important
• You start working across multiple remotes or forks: remote naming and sync habits matter more
• You hit the same Git mistake repeatedly: that is usually a sign your checklist or aliases need revision

Commands worth adding later

Once the basics are comfortable, consider expanding your personal cheat sheet with:

• git cherry-pick for applying one commit elsewhere
• git reflog for recovering from confusing history edits
• git bisect for finding the commit that introduced a bug
• git worktree for working on multiple branches at once

You do not need these on day one, but they become valuable as your projects and responsibilities grow.

Build your own return-to reference

The most practical next step is to copy the sections you use most into a personal team note, editor snippet, or project wiki. Keep only the commands your workflow actually needs. A short, trusted reference is more useful than a giant list you never scan.

Start with these categories:

• Status and inspection
• Branch creation and switching
• Staging and committing
• Syncing with remote
• Undo and recovery
• Conflict resolution

If you maintain onboarding notes for newer developers, include examples from your real branch naming rules, pull request flow, and preferred merge strategy. That turns a generic list of common git commands into a working team guide.

In practice, the best Git cheat sheet is not the one with the most commands. It is the one you trust when you are in the middle of real work, especially when you need to fix a mistake calmly. Keep it scenario-based, update it when your workflow changes, and return to it often enough that the safest commands become your default habits.