Git Best Practices

You now know the commands. This lesson collects the habits that make Git pleasant for you and your team: how to shape commits, manage branches, collaborate, and keep a repository safe and healthy.

Commits

  • One logical change per commit. A bug fix, a feature step, a rename — not all three. Use git add -p to separate mixed edits.
  • Commit early, commit often. Small commits are easy to review, revert and bisect. You can always combine them before sharing.
  • Write messages for the future reader. An imperative summary under about 50 characters, a blank line, then the why (lesson 10).
  • Review before committing. git status and git diff --staged catch debug output, stray files and secrets.
  • Each commit should work. Ideally every commit builds and passes tests — it makes git bisect reliable.
  • Separate formatting from logic. Reformatting a file in the same commit as a real change hides the real change.

Branches

  • Keep main working and protect it on your hosting service.
  • Branch for every change, with a descriptive name: fix/empty-basket, feature/gift-cards.
  • Keep branches short-lived and up to date with main; merge or rebase from it regularly.
  • Delete merged branches, locally and on the remote, and prune stale remote-tracking branches (fetch.prune).

History

  • Tidy before sharing, never after. Amend and interactively rebase your own unpushed commits freely; don't rewrite commits others have pulled.
  • Undo shared commits with git revert, not reset.
  • Prefer --force-with-lease over --force when you must overwrite your own remote branch.
  • Agree on a merge style (merge commits, squash or rebase) and stick to it.
  • Tag releases with annotated, ideally signed, tags and semantic versions.

Collaboration

  • Pull before you start, and before you push.
  • Small pull requests with a clear description, linked issues, and screenshots for UI changes.
  • Automate checks — tests, linting, formatting — in CI so reviews can focus on design and correctness.
  • Review kindly and promptly. Explain the reason behind suggestions; separate blocking issues from nitpicks.
  • Document the workflow in CONTRIBUTING.md and the project's setup in README.md.

Repository hygiene

  • Start with a good .gitignore for your language and tools, before the first commit.
  • Add a .gitattributes to normalise line endings and mark binary files.
  • Keep large binaries out, or in Git LFS.
  • Don't commit generated files — build output, dependencies, compiled assets — unless your deployment truly needs them.
  • Include a license for public projects, so others know how they may use the code.

Security

  • Never commit secrets. Keep them in ignored files or a secret manager; commit an example file with fake values.
  • If a secret leaks, rotate it first. Cleaning history comes second.
  • Turn on secret scanning and push protection where your host offers it — GitHub can block pushes that contain recognised keys.
  • Use two-factor authentication, SSH keys or a credential manager, and fine-grained, expiring tokens.
  • Sign commits and tags where authenticity matters.
  • Be careful with hooks and scripts from repositories you don't trust; they run code on your machine.

Your own setup

$ 
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main
git config --global pull.rebase true
git config --global push.autoSetupRemote true
git config --global fetch.prune true
git config --global merge.conflictStyle zdiff3
git config --global rebase.autoSquash true
git config --global alias.lg "log --oneline --graph --all --decorate"

A daily routine

$ 
git switch main && git pull            # start from the latest main
git switch -c feature/short-name       # one branch per task
# ...edit, then review and commit in small steps...
git status
git diff
git add -p
git commit
git pull --rebase origin main          # stay current while you work
git push                               # back up and share; open a pull request

Try it yourself

Pick one of your own repositories and audit it against this list: is there a .gitignore and .gitattributes? Are there merged branches to delete? Is main protected? Fix the two most important gaps.

PreviousTroubleshooting