Config Best Practices

The Hook (The "Byte-Sized" Intro)

A cluttered config is a ticking time bomb. That alias you copied from Stack Overflow two years ago? It overrides a default you didn't know about. That mysterious setting? Nobody remembers what it does. A clean, commented, minimal config is a config you can trust. Here are the rules.

📖 What are Config Best Practices?

Habits and guidelines for maintaining a Git configuration that is readable, safe, and easy to debug.

Conceptual Clarity

The 6 rules:

#	Rule	Why
1	Keep it minimal	Only add settings you understand and use
2	Comment your config	Future you needs to know why
3	Use local for project overrides	Don't pollute global with project-specific settings
4	Audit periodically	Remove settings you no longer use
5	Never store secrets	Use credential helpers instead
6	Version your config	Track changes in a dotfiles repo

Config anti-patterns:

❌ Anti-Pattern	✅ Better Approach
50+ aliases you don't use	5-10 aliases you use daily
Copy-pasted settings without understanding	Read the docs, test, then add
Secrets in `.gitconfig`	Use `git credential-manager`
Same config everywhere	`includeIf` for context-specific settings
Never reviewing config	Quarterly review and cleanup

Real-Life Analogy

Your Git config is like a toolbox. A clean toolbox has only the tools you use, organized and labeled. A messy toolbox has 50 tools you've never touched buried under the 5 you actually need.

Visual Architecture

flowchart TD MINIMAL["📏 Minimal"] --> CLEAN["✅ Clean Config"] COMMENTED["💬 Commented"] --> CLEAN VERSIONED["📦 Versioned"] --> CLEAN AUDITED["🔍 Audited"] --> CLEAN style CLEAN fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb

Why It Matters

Debuggability: A small config is easy to troubleshoot.
Safety: Understanding every setting prevents surprises.
Portability: A clean config transfers easily to new machines.
Trust: You can trust a config you understand.

Code

bash

# ─── Good: commented, minimal config ───
# ~/.gitconfig
# [user]
#     name = Jane Doe
#     email = jane@example.com
#
# [core]
#     editor = code --wait    # VS Code as editor
#
# [pull]
#     rebase = true           # Keep history linear
#
# [alias]
#     st = status -sb         # Short status
#     lg = log --oneline --graph --all --decorate

# ─── Audit your config ───
git config --global --list
# Review each setting — do you know what it does?

# ─── Remove a setting ───
git config --global --unset alias.old-alias

# ─── Review where settings come from ───
git config --list --show-origin --show-scope

# ─── Check for duplicate entries ───
grep -c "\[" ~/.gitconfig
# Compare with expected section count

Key Takeaways

Minimal: Only add settings you understand and actively use.
Commented: Add inline comments explaining non-obvious settings.
Versioned: Track your config in a dotfiles repo.
Audited: Review and clean up quarterly.

Interview Prep

Q: What are the most important Git config best practices? A: Keep it minimal (only settings you understand), comment non-obvious entries, use includeIf for context separation, never store secrets, and version your config in a dotfiles repo for portability.
Q: How do you debug unexpected Git behavior? A: Run git config --list --show-origin --show-scope to see every effective setting and where it comes from. This reveals overrides between system, global, and local levels.
Q: What is a credential helper and why should you use one? A: A credential helper stores authentication tokens securely (in the OS keychain) instead of in your .gitconfig file. git credential-manager is the recommended modern solution.