The 15 Git Commands Every Software Engineer Uses (And Why They Matter More Than You Think)

Source: Dev.to

Introduction

For a long time I thought Git was just something I had to survive—type a command, memorize it, and hope it worked. It felt intimidating because Git remembers every mistake, but once you stop treating it like magic and accept that it isn’t judging you, learning it becomes far less pressure‑filled. You don’t need 50 commands; a focused set of 15 used calmly and intentionally covers the vast majority of real‑world workflows.

git status — Check the Current State of Your Repository

Shows which files are modified, staged, untracked, or ready to be committed.

git status

Common mistake
Running git status and then committing or deleting the wrong files because you didn’t verify the output first.

git init — Initialize a New Git Repository

Creates a new Git repository by adding version‑control tracking to a project directory.

git init

Common mistake
Running git init inside an already‑initialized repo, which creates a nested .git folder and confuses Git.

git clone — Copy a Remote Repository Locally

Downloads a remote repository and creates a full local copy, including its commit history.

git clone 

git add — Stage Changes for the Next Commit

Moves file changes into the staging area so they can be included in the next commit.

git add .          # stage everything in the current directory
git add *          # stage all files (including hidden ones if the shell expands them)
git add -A         # stage all changes, including deletions

Common mistake
Using git add . blindly and accidentally staging files you didn’t intend to commit (e.g., large binaries or secrets).

git commit — Save a Snapshot of Your Changes

Records staged changes as a snapshot in the project’s history with a descriptive message.

git commit -m "Your concise, descriptive message"

Common mistake
Committing without a meaningful message or forgetting to stage the intended changes first.

git log — View the Commit History

Displays a list of previous commits, showing changes, authors, and timestamps.

git log
git log --oneline --graph --decorate   # compact, visual view

Common mistake
Assuming git log shows only the current branch’s history; it can include merged commits from other branches unless filtered.

git diff — See What Has Changed

Shows line‑by‑line differences between file versions, commits, or branches.

git diff                # unstaged changes
git diff --staged       # staged changes
git diff HEAD~1 HEAD    # changes between two commits

Common mistake
Skipping a review of git diff and committing code without knowing exactly what changed.

git branch — Manage Parallel Development

Create, list, rename, or delete branches for separate lines of development.

git branch               # list branches
git branch feature-x     # create a new branch
git branch -d old-branch  # delete a branch

Common mistake
Working directly on main (or master) instead of creating feature branches, which can lead to tangled histories.

git checkout / git switch — Move Between Branches Safely

Both commands let you switch branches; git switch is a newer, clearer alternative.

git checkout feature-x          # classic syntax
git switch feature-x             # recommended syntax
git checkout  --  # restore a file from a specific commit

Common mistake
Using git checkout to restore files without specifying the commit, unintentionally discarding local changes.

git merge — Combine Changes From Different Branches

Integrates changes from one branch into another, combining their histories.

git checkout main
git merge feature-x

Common mistake
Merging without first pulling the latest remote changes, leading to unnecessary conflicts.

git pull — Update Your Local Repository

Fetches changes from a remote repository and integrates them into your current branch (by merge or rebase, depending on configuration).

git pull               # default (usually merge)
git pull --rebase      # rebase instead of merge

Common mistake
Running git pull on a dirty working tree, which can cause merge conflicts or abort the operation.

git push — Share Your Commits With Others

Uploads your local commits to a remote repository so others can access them.

git push origin main
git push -u origin feature-x   # set upstream tracking

Common mistake
Pushing commits that haven’t been reviewed or that rewrite shared history (e.g., after a git reset --hard).

git stash — Temporarily Save Unfinished Work

Stores uncommitted changes so you can return to a clean working directory.

git stash               # save current changes
git stash list          # view saved stashes
git stash pop           # reapply the most recent stash and remove it
git stash apply stash@{2}  # apply a specific stash without dropping it

Common mistake
Forgetting to apply or drop a stash, leaving hidden changes that later cause confusion.

git reset — Undo Changes With Control

Moves the current branch pointer and optionally updates the staging area and working directory.

git reset --soft HEAD~1   # keep changes staged
git reset --mixed HEAD~1  # default: keep changes unstaged
git reset --hard HEAD~1   # discard all changes

Common mistake
Using --hard without realizing it permanently discards work, especially on shared branches.

git revert — Undo Changes Safely in Shared History

Creates a new commit that reverses the effects of a previous commit without rewriting history.

git revert 

Common mistake
Choosing git reset on a shared branch instead of git revert, which rewrites history and disrupts teammates.

Building Confidence with Git

Git confidence doesn’t arrive suddenly; it grows slowly as you use a core set of commands deliberately. One day you’ll stop panicking, run git status without hesitation, and know exactly what each command does.

Tip: Avoid copying commands blindly. Understand the intent behind each operation, and let Git become a tool you trust rather than a source of anxiety.

Happy committing! 💙