Do & Don't: the golden rules
Every rule here exists because something went wrong for somebody. Each has its reason attached, because a rule you understand is one you keep.
Committing
Do
- Commit early and often. A commit is the moment work becomes recoverable; nothing else in Git protects uncommitted work.
- One commit, one change. It reviews faster, reverts cleanly, and explains itself.
- Read
git diff --stagedbefore every commit. It is the last honest look at what you are recording. - Write the message for the person who will read it in a year. What changed, and why.
- Put the issue number in the message. It is what links the work together afterwards.
Don't
- Don't commit generated files, dependencies or build output. That is what
.gitignoreis for. - Don't commit secrets. Not even briefly: pushed is leaked, and rotating the credential is the fix.
- Don't bundle unrelated changes. The reviewer pays, and so does whoever reverts it.
- Don't write "fix", "wip" or "update" as a final message. Tidy them before review.
- Don't commit with an editor you have not configured, then panic in vi.
Branching
Do
- Start every branch from an updated
main. A stale start is the commonest avoidable cause of conflicts. - Name branches consistently, with the type and the issue number:
docs/12-windows-install-steps. - Keep branches short. Days, not weeks; a long branch conflicts with everything.
- Delete branches after merging, locally and remotely.
Don't
- Don't work directly on
main. Even for a one-line fix. - Don't let a branch live for a month. Split the work instead.
- Don't reuse a branch after it has merged. Start a fresh one.
Sharing
Do
- Pull before you start, and before you push.
- Push at least daily. Work in two places is work that cannot be lost.
- Use
--force-with-leaseif you must force, and only on your own branch. - Say so when you rewrite anything anyone else might have.
Don't
- Don't force-push a shared branch. It rewrites history under other people.
- Don't rebase a branch someone else has checked out.
- Don't push to a protected branch to "save time". The protection is the process.
Undoing
Do
- Ask "has this been pushed?" first. It decides between rewriting and reverting.
- Use
git revertfor anything published. It is the only safe undo for shared work. - Run
git statusandgit log --oneline -3before any fix. They change nothing and usually name the answer. - Learn
git reflogbefore you need it. It is what recovers a commit you thought was gone.
Don't
- Don't run
git reset --hardwith uncommitted work. That is the one irreversible everyday mistake. - Don't run
git clean -fdwithout-ndfirst. Untracked files have no safety net. - Don't add
-xtogit cleanunless you mean to delete your.envand your dependencies too. - Don't keep typing commands when you are lost. Stop, read, then act.
Reviewing
Do
- Say what you checked, especially when you checked only part.
- Batch your comments into one review.
- Suggest exact wording rather than describing the problem.
- Mark preferences as preferences, with "nit:" or "non-blocking:".
- Answer every thread, even with "done".
Don't
- Don't approve to be helpful. An approval is a statement.
- Don't redesign the change in review. Say the concern once and let the author decide how.
- Don't argue in chat. Keep it where the record is.
Security
Do
- Use the least powerful credential that works, with an expiry.
- Turn on two-factor authentication, everywhere.
- Rotate first if a secret was ever committed; clean history afterwards, if at all.
- Review your own tokens and keys every few months.
Don't
- Don't use a personal token for automation. It carries all your access and leaves with you.
- Don't put credentials in the repository, including in CI files.
- Don't rely on a hook as a control. It can be skipped with one flag.
- Don't assume a private repository is a secret store. Everyone with read access has all of it.
The four that matter most
If everything above is too much, these four prevent most of what goes wrong:
- Commit early, because nothing protects uncommitted work.
- Never rewrite what other people have.
- Read the message Git printed. It is nearly always the answer.
git reflogbefore you panic.