Git Best Practices That Senior Developers Actually Use

I was reviewing a pull request last week when I noticed something that made me cringe. A junior developer had committed directly to main, pushed a 47-file change with the message "fixes", and somehow managed to include their local database credentials in the process. We've all been there — or at least witnessed the aftermath. The thing is, Git best practices aren't just academic exercises. They're the difference between a smooth deployment and a 2 AM emergency call. After nearly a decade of working with distributed teams, I've seen what separates the developers who make Git look effortless from those who treat it like a necessary evil. Let me share the practices that actually matter in the real world.

Write Commit Messages Like You're Leaving Notes for Future You

Your commit message isn't documentation for the computer — it's a breadcrumb trail for humans. Six months from now, when a critical bug surfaces, you'll be digging through history trying to understand why something changed, not just what changed. The conventional format works well in practice: I've seen teams obsess over commit message formats while completely ignoring the content. Honestly, I'd rather see "fix: prevent null pointer in user service" than a perfectly formatted message that says nothing useful.

Branch Like Your Deployment Pipeline Depends On It

Because it does. The branching strategy that looks elegant in tutorials often falls apart when you're dealing with hotfixes, feature flags, and release schedules that change faster than startup pivots. Here's what works for most teams: - main: Always deployable, protected with required reviews - feature/ticket-123-user-authentication: Include ticket numbers when you have them - hotfix/critical-security-patch: For those "drop everything" moments

The Rebase vs. Merge Debate

Despite what the purists say, both have their place. Use rebase for cleaning up your feature branch before opening a PR. Use merge commits for integrating completed features — they preserve context about when features were integrated, which becomes invaluable during incident investigations. Most tutorials skip this part: interactive rebase (git rebase -i) is your friend for cleaning up commits before they hit the main branch. But never rebase shared branches. That way lies madness and very angry teammates.

The .gitignore File Is Your First Line of Defense

Every project needs a proper .gitignore from day one, not after someone accidentally commits node_modules. Start with a template from gitignore.io, but customize it for your specific setup. Common gotchas that only bite you once:

• IDE-specific files (.vscode/, .idea/)
• OS-generated files (.DS_Store, Thumbs.db)
• Environment files with secrets (.env, config.local.js)
• Build artifacts (dist/, build/, target/)
• Temporary files (*.log, *.tmp, .cache/)

Here's a gotcha that's caught more developers than they'd admit: .gitignore only affects untracked files. If you've already committed something and then add it to .gitignore, Git will keep tracking it. You need git rm --cached filename to stop tracking it.

Pull Requests: Code Review Theater vs. Actual Quality Gates

The best PR practices aren't about following a checklist — they're about making code review actually useful. Small, focused PRs get better reviews than 500-line monsters. Why? Because reviewers get fatigued, and after the first 200 lines, they're just skimming. In my experience, the magic number is around 200-400 lines of changes. Any bigger and you should probably split it up. Write PR descriptions like you're briefing someone who's been on vacation: - What problem does this solve? - How did you solve it? - What should reviewers focus on? - Any deployment notes or feature flags involved?

Git Hooks: The Automation You Didn't Know You Needed

Pre-commit hooks are like unit tests for your Git workflow — they catch problems before they become someone else's problem. Set up hooks to run your linter, tests, and security scans automatically. Tools like pre-commit make this painless: But here's the thing — make hooks fast or developers will find ways around them. Nobody wants to wait 30 seconds for a pre-commit hook to run. Keep the heavy lifting for your CI pipeline. The reality is that Git best practices aren't about memorizing commands or following rigid rules. They're about building workflows that scale with your team and make everyone's life easier. The practices that stick are the ones that solve real problems — not the ones that look good in conference slides. Think of Git like a shared language. The better everyone speaks it, the clearer your conversations become. And in software development, clear communication through code history can be the difference between debugging something in 5 minutes versus 5 hours. What Git practices have saved you the most time? The ones that seemed annoying at first often become the most valuable.