GitHub
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.

Key concepts

The idea

The Master Reference

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.

The Golden Rules

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

Walkthrough

Commits

✅ 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

Commit Message Template

type: short summary (50 chars)

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

Refs #42

Branches

✅ 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

History

✅ 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

Collaboration

✅ 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

Remotes

✅ 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

Security

✅ 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

Recovery

✅ 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

Workflow

✅ DO ❌ DON’T
Agree on team workflow Mix Git Flow and GitHub Flow
Document your conventions Assume everyone knows
Use CI/CD for testing Rely only on local tests
Require PR reviews Merge your own PRs
Use branch protection rules Allow direct pushes to main

Organization

✅ 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

Large Files & Scale

✅ 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

Key takeaways