Best Practices · lesson 18 of 18

The Dos and Don'ts

Git Best Practices Reference

Why it matters

After 17 lessons, here’s your cheat sheet. A comprehensive reference of everything you should and shouldn’t do with Git, organized by category.

This lesson consolidates all the dos and don’ts from the entire curriculum. Use it as a quick reference when you’re unsure about best practices.

Commit early, commit often—small commits are easier to understand and revert
Never rebase public history—you’ll break everyone’s clones
Never commit secrets—they’re in history forever
Write meaningful commit messages—your future self will thank you
Use branches for everything—main should always be deployable

✅ DO	❌ DON’T
Commit early and often	Batch many changes into one commit
Write meaningful messages	Use “fix”, “update”, “WIP”
Use imperative mood: “Add feature”	Use past tense: “Added feature”
Keep commits atomic (one purpose)	Mix unrelated changes
Reference issues: Refs #42	Leave commits orphaned

type: short summary (50 chars)

Longer explanation of WHY this change was needed.
The diff shows WHAT changed; the message explains WHY.

Refs #42

✅ DO	❌ DON’T
Use feature branches	Work directly on main
Use descriptive names: `feature/user-auth`	Use vague names: `my-branch`
Delete merged branches	Let stale branches accumulate
Keep branches short-lived	Let branches diverge for weeks
Pull/rebase from main regularly	Wait until merge to discover conflicts

✅ DO	❌ DON’T
Rebase local branches before pushing	Rebase pushed/shared branches
Use `revert` for public history	Use `reset` on public history
Squash before merging (if team prefers)	Leave “fix typo” commits in PR
Use interactive rebase for cleanup	Force-push to shared branches

✅ DO	❌ DON’T
Pull before pushing	Force-push without team agreement
Write clear PR descriptions	Open PRs without context
Respond to review feedback	Ignore or argue with reviewers
Keep PRs small and focused	Create 2000-line PRs
Test before opening PR	Push broken code for review

✅ DO	❌ DON’T
Use SSH keys for auth	Commit with HTTPS and passwords
Fetch before making assumptions	Assume your local is current
Name remotes clearly (origin, upstream)	Use confusing remote names
Push with `-u` to set upstream	Manually specify remote every time

✅ DO	❌ DON’T
Use .gitignore for secrets	Commit .env files, even “just for testing”
Use git-secrets or gitleaks	Rely on manual review
Sign commits on important repos	Assume user.name is trustworthy
Rotate leaked credentials immediately	Just delete the file and push
Enable GitHub secret scanning	Ignore security alerts

✅ DO	❌ DON’T
Check reflog when panicking	Panic and think data is lost
Use `revert` for pushed commits	Use `reset --hard` on pushed commits
Create backup branch before risky ops	YOLO dangerous operations
Understand reset modes (soft/mixed/hard)	Use `--hard` without thinking

✅ DO	❌ DON’T
Use clear issue descriptions	Create vague issues
Link PRs to issues	Leave issues orphaned
Use labels and milestones	Let issues pile up without organization
Close issues with context	Close without explanation

✅ DO	❌ DON’T
Use Git LFS for binaries	Commit large files directly
Use sparse checkout for monorepos	Clone entire monorepo unnecessarily
Clean up submodules	Let submodules go stale
Keep repo size reasonable	Let history bloat with binaries