Git Notes
Essential Git best practices for professional developers. Commit conventions, branching etiquette, code review habits, and repository maintenance.
The difference between a junior developer's Git history and a senior developer's is immediately visible. Junior histories look like "fix", "update", "WIP", "asdf", "trying something". Senior histories read like a clean narrative: each commit tells a story, branches are focused, and the repository is a joy to navigate.
These are not arbitrary preferences — they are practices that make collaboration smoother, debugging faster, code reviews more effective, and repositories easier to maintain over years. Let us walk through the habits that separate professional Git usage from amateur hour.
Commit Best Practices
Write Meaningful Commit Messages
Your commit messages are documentation for your future self and your teammates. They answer "why was this change made?" months later when someone is debugging a regression:
# ✅ Good: Descriptive, explains the change
git commit -m "feat(auth): add JWT refresh token rotation"
git commit -m "fix(cart): resolve race condition when updating quantity"
git commit -m "refactor(api): extract validation into middleware"
git commit -m "docs: add API authentication examples to README"
git commit -m "perf(search): add database index for full-text queries"
# ❌ Bad: Meaningless, unhelpful to anyone reading later
git commit -m "fix"
git commit -m "updates"
git commit -m "WIP"
git commit -m "stuff"
git commit -m "address comments"
git commit -m "final fix (for real this time)"Use Conventional Commits
The Conventional Commits specification gives your history machine-readable structure:
# Types and their meanings:
feat # New feature (triggers MINOR version bump)
fix # Bug fix (triggers PATCH version bump)
docs # Documentation only changes
style # Formatting, semicolons, etc. (no code change)
refactor # Code change that neither fixes a bug nor adds a feature
test # Adding or correcting tests
chore # Build process, tooling, dependencies
perf # Performance improvement
ci # CI/CD configuration changes
build # Build system changes
revert # Reverts a previous commitBenefits: automated changelog generation, semantic versioning, clear history filtering (git log --grep="feat:"), and team consistency.
Make Atomic Commits
Each commit should represent exactly one logical change. If you need the word "and" to describe it, split it into two commits:
# ✅ Atomic: each commit has one purpose
git commit -m "feat: add user registration form component"
git commit -m "feat: add form validation with error messages"
git commit -m "feat: connect registration to API endpoint"
git commit -m "test: add integration tests for registration flow"
# ❌ Non-atomic: multiple unrelated changes bundled
git commit -m "Add registration, fix navigation, update styles, refactor DB queries"Atomic commits enable:
- Easy reverts (revert one change without affecting others)
- Clear git blame (know exactly when and why each line changed)
- Effective bisection (find bugs faster with granular commits)
- Meaningful code review (reviewers understand the logical progression)
Commit Frequently, Push Daily
# Commit whenever you complete a logical unit of work
# This is typically every 30-60 minutes of focused coding
# Push at least once daily for:
# - Backup (your laptop could die tomorrow)
# - Team visibility (others can see progress)
# - CI feedback (catch issues early)Branching Best Practices
- Always start from updated main:
git checkout main && git pull && git checkout -b feature/... - Use descriptive branch names:
feature/JIRA-123-user-dashboardnotfeature/stuff - Keep branches short-lived: Merge within 1-3 days maximum
- One purpose per branch: Never mix feature development with refactoring
- Delete after merging: Keep the branch list relevant to active work
- Rebase from main regularly: Daily rebasing prevents massive conflicts
# Good branch names
feature/PROJ-456-user-notifications
fix/login-timeout-on-slow-networks
refactor/extract-payment-service
docs/api-authentication-guide
hotfix/critical-security-patch
# Bad branch names
my-branch
test
temp
fix2
johns-workPull Request Best Practices
- Keep PRs under 400 lines — Smaller reviews catch more bugs and get reviewed faster
- Write descriptive titles and descriptions — Explain the WHY, not just the what
- Include screenshots for UI changes — Reviewers should not need to run your code to see visual changes
- Self-review before requesting — Read your own diff first and catch obvious issues
- Respond to feedback within 24 hours — Do not block reviewers
- Use draft PRs for early feedback — Signal that work is not ready for final review
- Link to issues or tickets — Connect the PR to the broader context
- Add context for non-obvious decisions — Comments on your own PR explaining tradeoffs
Repository Maintenance
Healthy repositories require periodic maintenance:
# Weekly: Clean up your local environment
git fetch --prune # Remove stale remote references
git branch --merged main | grep -v main | xargs git branch -d # Delete merged branches
# Monthly: Repository health
git gc # Garbage collection and compression
git remote prune origin # Clean stale remote-tracking branches
# Ongoing: Keep essential files current
# - README with setup instructions and architecture overview
# - CONTRIBUTING.md with workflow documentation
# - .gitignore updated for new tooling
# - Branch protection rules reviewedSecurity Best Practices
- Never commit secrets (API keys, passwords, tokens, connection strings)
- Use
.gitignorefor sensitive files before they ever get tracked - Enable branch protection on main and release branches
- Enable secret scanning and push protection
- Sign commits with GPG or SSH keys
- Use SSH keys or tokens instead of passwords
- Regularly rotate credentials and review access permissions
Common Mistakes and How to Avoid Them
Mistake 1: Giant commits with git add . and vague messages. Instead, use git add -p for interactive staging and write specific messages.
Mistake 2: Working directly on main. Always create a branch, even for small changes, so you have the option of review.
Mistake 3: Not pulling before starting work. You end up building on stale code, creating unnecessary conflicts.
Mistake 4: Force pushing to shared branches. Only force push to your personal feature branches.
Mistake 5: Not using .gitignore from the start. Add it in your first commit to prevent accidentally tracking generated files, dependencies, or secrets.
Interview Questions
Q1: What are your Git commit message conventions?
I use Conventional Commits: type(scope): description. Messages are under 72 characters for the subject line, explain the why in the body if needed, and reference issue numbers. This enables automated changelogs and consistent, searchable history.
Q2: How do you keep your Git history clean?
Atomic commits (one logical change each), meaningful messages following conventions, interactive rebase to squash WIP commits before merging, consistent branch naming, and short-lived branches that are deleted after merge.
Q3: What is your branching strategy?
Feature branches from latest main with descriptive naming including ticket numbers, short-lived (1-3 days), rebased from main daily, integrated through PRs with required reviews. Delete branches after merge.
Q4: How do you handle large PRs?
Avoid them by planning work as vertical slices. If a PR grows large, break it into sequential smaller PRs. Use stacked PRs if the work is dependent. Feature flags allow merging partial implementations safely.
Q5: What repository maintenance do you perform regularly?
Prune stale branches (locally and remotely), update documentation (README, CONTRIBUTING), review and close stale issues, keep dependencies current via Dependabot, audit access permissions quarterly, and ensure CI/CD stays fast and green.
Exam Focus
Revise definitions, diagrams, examples, and short-answer points for Git Best Practices - Professional Development Habits.
Interview Use
Prepare one clear explanation, one practical example, and one common mistake for this Git & GitHub topic.
Search Terms
git-github, git & github, git, github, resources, best, practices, git best practices - professional development habits
Related Git & GitHub Topics