Git Workflow Best Practices Every Developer Should Know

Git is the tool every developer uses daily and few people truly master. You don’t need to know every command — but a handful of good habits will make your history cleaner, your code reviews easier and your mistakes reversible.

1. Write commit messages people can understand

A good commit message explains what changed and why. The widely used convention:

Short summary in the imperative (max ~50 chars)

Longer explanation of what and why, wrapped at 72 characters.
Mention the problem being solved, not just the code touched.

Fixes #142

Compare these:

• ❌ fixed stuff
• ❌ update
• ✅ Fix checkout crash when cart is empty
• ✅ Add rate limiting to login endpoint

Many teams also use Conventional Commits prefixes such as feat:, fix:, docs: and refactor:, which allow changelogs to be generated automatically.

2. Make small, focused commits

One commit = one logical change. Small commits are easier to review, easier to understand later and much easier to revert if something breaks.

Use interactive staging to commit only part of a file:

git add -p        # review and stage changes hunk by hunk
git commit

3. Use short-lived feature branches

Keep main always deployable. Do your work on a branch named after what you’re doing:

git switch -c feature/user-avatars
# ...work, commit...
git push -u origin feature/user-avatars

Then open a pull request. Branches that live for weeks drift away from main and create painful merge conflicts — aim to merge within a few days.

Use git switch and git restore instead of the older, overloaded git checkout. They’re clearer and harder to misuse.

4. Stay up to date with main

Regularly bring the latest changes into your branch so conflicts stay small:

git fetch origin
git rebase origin/main     # or: git merge origin/main

Rebase gives a clean, linear history; merge preserves exactly what happened. Both are fine — just agree as a team.

Never rebase a branch that other people are also working on. Rebasing rewrites history and will cause headaches for everyone else who has pulled it.

5. Tidy up before you share

Before opening a pull request, you can squash “oops” and “typo” commits into meaningful ones:

git rebase -i origin/main

In the editor, change pick to squash (or fixup) for commits you want to combine.

6. Use a proper .gitignore

Never commit build output, dependencies, editor settings or secrets. A typical web project might include:

node_modules/
dist/
.env
.DS_Store
*.log
.vscode/

Templates for almost every language are available at github.com/github/gitignore.

7. Never commit secrets

API keys and passwords in Git history are effectively public once pushed — even if you delete them in a later commit. Keep them in environment variables or a secrets manager. If a secret does leak, rotate it immediately; deleting it from history isn’t enough.

Commands that save the day

git status                     # what's going on right now?
git log --oneline --graph      # compact visual history
git diff --staged              # review what you're about to commit

git commit --amend             # fix the last commit message or add a forgotten file
git restore <file>             # discard uncommitted changes to a file
git stash / git stash pop      # park work in progress temporarily
git revert <commit>            # safely undo a commit that's already pushed

git reflog                     # find "lost" commits after a bad reset or rebase

git reflog is the ultimate safety net: it records where your branch pointed at every step, so even “deleted” commits can usually be recovered.

Summary

Write clear messages, keep commits small, use short-lived branches, sync with main often and keep secrets out of your repo. Master these habits and Git stops being scary — it becomes your time machine.