Home / DevOps / Git Best Practices / Git Best Practices Checklist

Git Best Practices Checklist: DevOps Team Guidelines and Standards

25 min read
Best Practices · Standards
Updated: Feb 2026

Building a Culture of Git Excellence

Git is more than just a version control tool—it's the foundation of your team's collaboration, deployment pipeline, and code integrity. This comprehensive checklist codifies industry-proven best practices into actionable items your team can implement today. Use it as a living document during onboarding, code reviews, and process retrospectives.

How to Use This Checklist: Each item includes a checkbox for tracking, a priority badge (Required/Recommended/Optional/Team-specific), a detailed explanation, and examples. Work through sections progressively, or use as a reference during PR reviews. The scorecard at the end helps measure your team's Git maturity.

0
/ 50 points - Git Maturity Score
🔴 Critical: 0-20 🟡 Developing: 21-35 🟢 Mature: 36-50
📝
1. Commit Message Conventions
Use conventional commits format Required
Structure commit messages as <type>[optional scope]: <description> for automatic changelog generation and semantic versioning.
feat(auth): add OAuth2 login flow
fix(api): handle null response in user service
docs: update README with setup instructions
refactor: simplify payment validation logic
test: add unit tests for login component
💡 Types: feat, fix, docs, style, refactor, perf, test, chore. Breaking changes: add "!" or "BREAKING CHANGE:" in footer.
Write commits in present tense imperative Required
Use "Add feature" not "Added feature" or "Adds feature". Commits should complete the sentence "This commit will..."
✅ "Add validation to payment form"
❌ "Added validation"
❌ "Adding validation"
❌ "Adds validation"
Keep commits atomic and focused Required
Each commit should represent one logical change. Avoid bundling unrelated changes (e.g., bug fixes + refactoring + formatting in one commit).
✅ Good: Three separate commits
commit 1: "fix: resolve null pointer in login"
commit 2: "refactor: extract validation logic"
commit 3: "style: format code according to prettier"

❌ Bad: One commit
"fix login and refactor validation and format code"
💡 Use git add -p to stage only parts of files for atomic commits.
Include context in commit body when needed Recommended
For non-trivial changes, explain the "why" not just the "what". Include ticket numbers, design decisions, or alternative approaches considered.
feat: implement rate limiting for API

Why: Prevent abuse of public endpoints following security audit
How: Using token bucket algorithm with Redis backend
Ticket: SEC-1234

Alternative considered: Leaky bucket - rejected due to burst handling requirements
Link commits to issues/tickets Recommended
Include issue IDs in commit messages for traceability. Most Git hosts auto-link when using syntax like #123, JIRA-123, or [PROJ-123].
feat(api): add pagination to user endpoint #456
fix: correct calculation in tax module JIRA-789
docs: update deployment guide [DEVOPS-234]
Never commit generated files Required
Don't commit build artifacts, dependencies, IDE files, or logs. Use .gitignore to prevent accidental commits.
# Good .gitignore patterns
node_modules/
dist/
build/
*.log
.env
.idea/
*.class
vendor/
🌿
2. Branching Strategy and Naming
Choose and document a branching strategy Required
Select a branching model that fits your release cadence and team size. Document it clearly for all team members.
Options:
• GitHub Flow: main + feature branches. Simple, continuous delivery.
• GitFlow: main, develop, feature/*, release/*, hotfix/*. Good for scheduled releases.
• GitLab Flow: Adds environment branches (production, staging).
• Trunk-based: Short-lived branches, direct merges to main.
Use consistent branch naming conventions Required
Standardize branch naming for clarity and automation. Include type, ticket ID, and brief description.
feature/user-authentication
feature/JIRA-123-payment-integration
bugfix/login-error
hotfix/security-patch-2.1.1
release/v2.5.0
chore/update-dependencies
Keep branches short-lived Recommended
Aim to merge feature branches within 1-3 days. Longer-lived branches increase merge conflicts and integration pain.
💡 If a branch lives longer than a week, consider merging to main with feature flags or breaking into smaller chunks.
Delete branches after merging Recommended
Clean up both local and remote branches after they're merged. Keeps repository clutter-free.
# Delete remote branch
git push origin --delete feature/old-branch

# Delete local branch
git branch -d feature/merged-branch

# Prune remote-tracking branches
git remote prune origin
Protect main/default branch Required
Enable branch protection rules to prevent direct pushes and enforce quality checks.
Required protections:
• Require pull request reviews (minimum 2)
• Dismiss stale reviews
• Require status checks (CI passes)
• Require signed commits
• No force pushes
• Linear history (no merge commits)
👀
3. Code Review and Pull Request Standards
Keep PRs focused and manageable Required
Limit PRs to 200-400 lines changed. Larger PRs are harder to review and more likely to contain bugs.
💡 Break large features into multiple PRs with feature flags to maintain continuous integration.
Write descriptive PR titles and descriptions Required
PR descriptions should explain the what, why, and how. Include screenshots for UI changes.
Title: feat: Add rate limiting to API endpoints

Description:
## What
Implements token bucket rate limiting on public API routes

## Why
Following security audit SEC-123, we need protection against DoS attacks

## How
Uses Redis for distributed rate limiting with configurable limits

## Testing
- Unit tests added
- Manual tested with 100 requests/second

## Screenshots
[image]
Require at least one reviewer Required
Every PR must be reviewed by at least one other team member. Critical code may require two approvals.
Review within 24 hours Team-specific
Establish a team norm for review turnaround. Fast reviews keep momentum and reduce context switching.
Use checklist in PR template Recommended
Include a self-check section in PR template to ensure common quality gates are met.
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] No secrets committed
- [ ] Follows commit message conventions
- [ ] Branch up to date with main
🔐
4. Security and Access Control
Never commit secrets Required
No API keys, passwords, tokens, or certificates in repositories. Use environment variables or secrets managers.
# Wrong: hardcoded secrets
API_KEY = "sk_live_12345abcde"

# Right: environment variables
API_KEY = process.env.API_KEY

# Or secrets manager
API_KEY = aws secretsmanager get-secret ...
Use pre-commit hooks for secret detection Recommended
Automatically scan for potential secrets before they reach the repository.
# .git/hooks/pre-commit
#!/bin/sh
git diff --cached | grep -E "(password|api_key|secret|token|AKIA)" && exit 1

# Or use tools like git-secrets, truffleHog, gitleaks
Enable secret scanning in Git hosting Required
Turn on built-in secret scanning (GitHub, GitLab, Bitbucket) to detect accidentally committed secrets.
Sign commits with GPG Recommended
Use signed commits to verify authorship and prevent impersonation. Enable "Require signed commits" on main branch.
# Configure signing
git config --global user.signingkey [KEY-ID]
git config --global commit.gpgSign true

# Sign commit
git commit -S -m "feat: add payment"
Use SSH keys with passphrases Required
Protect SSH private keys with strong passphrases. Use ssh-agent to cache them securely.
Rotate access keys regularly Recommended
Set up key rotation policies for SSH keys, deploy keys, and service accounts. Revoke keys when team members leave.
🔄
5. CI/CD and Automation
Run CI on all branches Required
Run tests and checks on every push to catch issues early, not just on main.
Require CI status checks to pass Required
Configure branch protection to block merging if CI fails.
Use path-based triggers for monorepos Team-specific
In monorepos, trigger CI only for changed services to save resources.
# GitHub Actions example
on:
push:
paths:
- 'api/**'
- 'shared-libs/**'
Cache dependencies in CI Recommended
Speed up builds by caching package managers' caches (npm, pip, maven, etc.).
Use semantic versioning with tags Recommended
Tag releases with semantic versions (v1.2.3). Automate tagging in CI when releasing.
👥
6. Team Workflow and Communication
Document Git workflow Required
Maintain living documentation of team Git practices: branching, commit conventions, release process.
Onboard new team members Recommended
Pair with new hires on their first PRs. Walk them through team conventions and tooling.
Use CODEOWNERS for required reviews Team-specific
Automatically request reviews from teams responsible for specific code areas.
# .github/CODEOWNERS
/api/ @backend-team
/web/ @frontend-team
/infra/ @devops-team
Regular workflow retrospectives Recommended
Periodically review Git practices as a team. What's working? What's causing friction?
🧹
7. Repository Health and Maintenance
Regularly run garbage collection Recommended
For bare repositories on servers, run git gc periodically to optimize performance.
Monitor repository size Recommended
Keep an eye on repository size. Investigate if it grows unexpectedly.
# Check size
git count-objects -vH

# Find large files
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | grep "^blob" | sort -k3 -n -r | head -10
Use Git LFS for large binaries Team-specific
If your project includes large binary files (>10MB), use Git LFS to prevent repository bloat.
Regular backups Required
Ensure Git hosting is backed up. For self-hosted, implement backup strategy.
📦
8. Release and Versioning Practices
Tag all releases Required
Every release should have a signed tag with release notes. Use semantic versioning.
git tag -s v2.1.0 -m "Release v2.1.0: Add payment integration"
Maintain changelog Recommended
Keep a CHANGELOG.md following Keep a Changelog format. Automate with conventional commits.
Hotfix process documented Required
Document emergency hotfix procedure: create from tag, fix, merge to main and develop.
Category Key Practices
Commits Conventional format, atomic, present tense, no secrets
Branches Consistent naming, short-lived, delete after merge, protect main
PRs Small, descriptive, reviewed, CI passing
Security Signed commits, secret scanning, SSH keys, rotate access
CI/CD Run on all branches, require status checks, cache dependencies
Team Documented workflow, onboarding, retrospectives
Maintenance Monitor size, LFS for binaries, backups
Releases Tag releases, changelog, hotfix process
📈
Team Implementation Progress
Critical Items (Required) 0/20
Recommended Items 0/15
Team/Context Specific 0/15
A developer pushes a commit with the message "fixed stuff". Which best practice is being violated?
  • Commit message should be descriptive and follow conventions
  • Commits should be signed with GPG
  • Branches should be protected
  • CI should run on all branches

Best Practices FAQ

How do we enforce these practices without creating friction?

Balance enforcement with developer experience:

  1. Automate what you can: Use pre-commit hooks for formatting, CI for tests, branch protection for rules.
  2. Start small: Implement 2-3 practices at a time. Let the team adapt before adding more.
  3. Lead by example: Senior team members should model good practices.
  4. Document the "why": Explain the reasoning behind each practice.
  5. Provide tooling: Create aliases, scripts, and templates that make following practices easier.
  6. Review periodically: Retrospect on practices—are they helping? Are any causing unnecessary overhead?
How do we handle legacy repositories that don't follow these practices?

Strategies for legacy codebases:

  1. Don't rewrite history: For shared repositories, avoid cleaning up old commits. Start fresh with new commits following standards.
  2. Document the baseline: Note in README which practices apply to new contributions.
  3. Gradual improvement: When touching old files, you can improve them (boy scout rule).
  4. Consider branch rewrite for critical repos: If the repository is small and team can coordinate, use filter-repo to clean history once.
  5. Update contribution guide: Clearly state expectations for new commits regardless of history.
How often should we review and update these practices?

Recommended review cadence:

  • Quarterly team retrospectives: Discuss what's working, what's not.
  • After onboarding new team members: Fresh eyes often spot confusing practices.
  • When adopting new tools: CI/CD changes may enable new practices.
  • When scaling team size: What worked for 5 people may not work for 20.
  • Annually formal review: Document any changes and communicate to team.
What's the single most impactful practice for a new team?

For a team just starting with Git best practices, focus on:

Commit message convention + branch protection on main.

These two practices provide immediate benefits:

  • Commit messages make history readable and enable automation.
  • Branch protection prevents mistakes reaching main and enforces reviews.

From there, gradually add automated testing, signed commits, and other practices as the team matures.

Previous: Hands-on Exercises Next: Advanced Rebase

Master Git Best Practices