Git Your Way: Essential Commands Every Developer Should Master

Most of what I know about Git I learned by cleaning up after myself. A merge that went sideways, a commit I wanted to undo, a config file that went up to a public repo with a key in it. Version control is not usually taught as a subject; you pick it up while shipping something, and the first month is mostly damage control.

The reassuring part is that a dozen commands cover almost all of daily work. Here are the ones I actually type, grouped the way I tend to need them.

Basic commands

• git init

  creates a new Git repository in the current directory.

• git clone <url>

  creates a local copy of a remote repository. This is also the fastest way to start a project from a template instead of writing boilerplate, which is basically the argument in why I stopped starting from scratch.

• git config --global user.name "Your Name"

  and

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

  set the identity attached to every commit you make. Do this once per machine, otherwise Git either refuses to commit or attaches whoever the machine belongs to.

• git status

  shows what is staged, what is modified, and what Git is not tracking yet. I run this more than anything else on this page.

• git add <file>

  stages a file or directory for the next commit;

  git add .

  stages everything under the current directory.

• git commit -m "message"

  records a snapshot of the staged changes. Write the message for the person reading it in six months, because that person is usually you.

Branching and merging

• git branch

  lists local branches, or creates one if you pass a name.

• git checkout <branch_name>

  switches to another branch.

• git checkout -b <branch_name>

  creates a branch and switches to it in one step.

• git merge <branch_name>

  merges another branch into the one you are currently on.

Since Git 2.23 there are narrower commands that do the same work without

checkout

's overloaded behaviour:

git switch <branch_name>

and

git switch -c <branch_name>

for branches,

git restore <file>

to throw away local changes in a file.

checkout

still works and every tutorial online uses it, so you will see both. I use

switch

now, mostly because it cannot silently discard a file when I meant to change branches.

Remote repositories

• git remote add origin <url>

  links your local repository to one on GitHub, GitLab or wherever the code lives.

• git pull

  fetches changes from the remote and merges them into your branch.

• git push

  uploads your local commits.

• git push -u origin <branch_name>

  does the same thing for a new branch and remembers where it came from, so later pushes are just

  git push

  .

Viewing history

• git log

  shows commit history. On a real project I use

  git log --oneline --graph --decorate

  , which fits far more history on one screen and shows where branches split.

• git diff

  shows unstaged changes;

  git diff --staged

  shows what you are about to commit. That second one is worth getting in the habit of.

Commands that save you on a bad day

• git stash

  shelves your uncommitted changes so you can switch context;

  git stash pop

  brings them back. I use this constantly when I need to test something on a clean tree.

• git rm <file>

  removes a file from the working directory and stages the deletion in one step.

• git reset --soft HEAD~1

  undoes the last commit and leaves the changes staged, which is what you want when the message was wrong.

• git revert <commit>

  creates a new commit that reverses an old one without rewriting history, which is the safe option on a shared branch.

Workflows, chained commands and gitty situations

Two habits cut most of the friction for me.

The first is a chained one-liner for the add, commit and push cycle. Once you are pushing several times an hour, typing them separately is wasted keystrokes:

git add . && git commit -m "add validation to the post editor" && git push origin dev

Swap the branch name and the message, save it as a snippet or a shell alias, and it works for most of a workday's commits. This is the same loop that a

git push

based deploy runs on the other side; if you are curious what happens after the push, I wrote about deploying with Coolify on a VPS.

The second is removing files that are already committed and pushed. Say you committed build output, or a

.env

file, at the root of the repository:

git rm <file1> <file2>
git commit -m "Remove unwanted files from root directory"
git push

And the same thing chained:

git rm <file1> <file2> && git commit -m "Remove unwanted files from root directory" && git push

One warning that has cost me real time: if the file you removed contained a credential, deleting it in a new commit is not enough. The value stays in history and anyone who can clone the repo can read it. Rotate the key or token first, then clean the history with

git filter-repo

if the repository is public.

These are the commands I reach for daily. There is a lot more Git than this. When I need something specific, the Atlassian Git tutorials are the reference I keep coming back to, and

git help <command>

is faster than any search engine.