Essential Git Commands for Daily Work

For a daily development workflow, the essential Git commands are git status, git add, git commit, git push, git pull, git branch, git checkout/git switch, git merge, and git log. These cover the core cycle of saving your work, syncing it with a remote, and managing branches. This article explains each command, how they fit together, and the most common pitfalls developers hit.

What Git Actually Tracks

Git is a distributed version control system. Unlike older tools like SVN, every developer has a full copy of the repository history, not just the latest snapshot. Git stores content as a series of snapshots called commits. Each commit records the state of your files, a message, an author, a timestamp, and a reference to its parent commit. This creates a directed acyclic graph of history that you can navigate, branch, and merge.

Your working directory is separate from Git’s internal database. Files exist in one of three states:

Modified – you changed a file but haven’t staged it.
Staged – you marked changes to be included in the next commit.
Committed – the snapshot is safely stored in the repository.

The command git status shows which state each file is in. It is the first command you should run every morning to see what has changed since yesterday.

The Core Daily Cycle

Most days follow a simple loop: pull the latest changes, make edits, stage them, commit, and push. Here is the exact sequence with explanations.

git pull – fetches changes from the remote and merges them into your current branch. Use git pull --rebase if you prefer a linear history and have no local commits that conflict.
git status – see which files are modified, staged, or untracked.
git add <file> – stage a specific file. Use git add . to stage all changes, but be careful: this also stages deletions and new files. Review with git status before committing.
git commit -m "message" – create a snapshot with a clear message. A good message explains why, not just what. For example, “Fix login redirect after password reset” is better than “Update auth.js”.
git push – upload your commits to the remote repository. If your branch is new, use git push -u origin <branch> to set the upstream tracking.

That loop is the heart of daily Git usage. The rest of the commands exist to handle branching, merging, and recovering from mistakes.

Branching and Switching

Branches are lightweight pointers to commits. They let you work on features, fixes, or experiments in isolation. The default branch is usually called main or master.

git branch – list local branches. The current branch has an asterisk.
git branch <name> – create a new branch at your current commit.
git switch <branch> – move to another branch. This updates your working directory to match that branch’s files.
git switch -c <name> – create and switch in one step. This is the most common way to start a new feature.
git branch -d <name> – delete a branch that has been merged.

The older command git checkout still works for switching, but git switch is clearer and less overloaded. Use git checkout -- <file> to discard changes in a file – that is a different operation from switching branches.

Merging and Resolving Conflicts

When you finish a feature branch, you want to integrate it back. The two main ways are git merge and git rebase.

git merge <branch> creates a new commit that combines the histories of the current branch and the target branch. It preserves the exact history, including all the individual commits from the feature branch. This is the safest and most common approach.

git rebase <branch> replays your commits on top of another branch, producing a linear history. It makes the log cleaner but rewrites commit hashes. Never rebase commits that others have already pulled.

Conflicts occur when two branches change the same line of the same file. Git marks the file with <<<<<<<, =======, and >>>>>>> markers. You must manually edit the file to choose the correct content, then run git add <file> and git commit to finish the merge. Tools like git mergetool can help, but the manual edit is unavoidable.

Inspecting History and Finding Bugs

Understanding what changed and why is a daily task. The git log command is your window into history.

git log --oneline – compact list of commit hashes and messages.
git log --graph --all – visual representation of branches and merges.
git log -p <file> – show the actual diffs for a specific file.
git blame <file> – show which commit and author last modified each line. This is invaluable when you need to ask “who changed this line and why?”.
git diff – show unstaged changes. git diff --staged shows what you have staged.

If you need to find when a bug was introduced, git bisect performs a binary search through history. You mark a known-good commit and a known-bad commit, and Git checks out the midpoint for you to test. This can reduce a 100-commit search to about 7 checks.

Undoing Mistakes Safely

Mistakes happen. Git gives you several ways to undo, but they differ in severity.

git restore <file> – discard uncommitted changes in a file. This is permanent; you cannot recover them.
git restore --staged <file> – unstage a file but keep your changes.
git commit --amend – replace the last commit with a new one. Use this to fix a typo in the message or add a forgotten file. Only amend commits you have not pushed.
git reset --hard <commit> – move the current branch to a specific commit and discard all changes after it. This is destructive. Use git reset --soft to keep changes staged, or git reset (mixed) to keep them unstaged.
git revert <commit> – create a new commit that undoes the changes of a previous commit. This is the safe way to undo pushed history because it does not rewrite existing commits.

A common misconception is that git reset and git revert are interchangeable. They are not. Reset moves the branch pointer and can destroy history; revert adds a new commit and preserves history. On a shared branch, always use git revert.

Stashing and Temporary Work

Sometimes you are in the middle of a change and need to switch branches urgently – for example, to fix a hot bug. You do not want to commit half-finished work. git stash saves your uncommitted changes and cleans your working directory.

git stash – save changes and revert to the last commit.
git stash list – show all saved stashes.
git stash pop – apply the most recent stash and remove it from the list.
git stash apply – apply a stash but keep it in the list, useful if you need it in multiple branches.
git stash drop – delete a stash.

Stashes are not a backup system. They are temporary and can be lost if you run git stash clear or if the repository is deleted. For longer-term work-in-progress, create a branch and commit there.

Frequently Asked Questions

What is the difference between `git pull` and `git fetch`?

git fetch downloads new commits from the remote but does not change your working directory. git pull does a fetch and then immediately merges (or rebases) those changes into your current branch. Use git fetch when you want to inspect remote changes before integrating them.

Why did my `git push` get rejected?

This usually means the remote branch has commits you do not have locally. Run git pull to integrate those changes, resolve any conflicts, and then push again. If you are certain your local history is correct, you can force push with git push --force, but that overwrites remote history and should be avoided on shared branches.

How do I rename a branch?

If you are on the branch, run git branch -m <new-name>. If you are on a different branch, use git branch -m <old-name> <new-name>. After renaming, if the branch was already pushed, delete the old remote branch and push the new one.

What does `HEAD` mean in Git?

HEAD is a pointer to the commit you are currently on. It usually points to a branch name, which in turn points to a commit. When you check out a specific commit directly, HEAD becomes detached, meaning you are not on any branch. Any new commits you make will not belong to a branch and can be lost if you switch away.

Should I use `git merge` or `git rebase`?

For most daily work, merge is safer because it preserves history and does not rewrite commits. Rebase gives a cleaner linear history but rewrites commit hashes, which can cause problems for anyone else who has those commits. Use rebase for local cleanup before pushing, and merge for integrating shared branches.

How do I ignore files I do not want to commit?

Create a file named .gitignore in the repository root. Each line is a pattern for files or directories to ignore, such as node_modules/ or *.log. Once a file is tracked, adding it to .gitignore will not untrack it; you must run git rm --cached <file> to remove it from the index while keeping it on disk.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →