Git Best Practices for Branching and Approvals

Amaresh Pelleti
Git Best Practices for Branching and Approvals

Managing a Git repository effectively requires more than just committing code — it’s about maintaining clear branching strategies and efficient approval workflows.
Without these, teams can face merge conflicts, code quality issues, and deployment delays.

This article is part of our complete Git and GitHub Actions workflow guide.

In this guide, we’ll cover the best practices for Git branching and pull request approvals that can keep your development process smooth and predictable.

1. Choose the Right Branching Strategy

Your branching strategy defines how features, fixes, and releases are developed. Here are the most common patterns:

a) Git Flow (Best for complex projects)

  • main – production-ready code
  • develop – integration branch for features
  • feature/ – per-feature branches
  • release/ – staging branches before production
  • hotfix/ – urgent fixes to main

Example:

git checkout -b feature/login-page develop

💡 When to use: Large teams with multiple release cycles.

b) GitHub Flow (Best for continuous deployment)

  • main – always deployable
  • feature branches – short-lived, merged quickly

Example:

git checkout -b fix/navbar-bug main

💡 When to use: Smaller teams or products that deploy frequently.

c) Trunk-Based Development (Best for rapid integration)

  • Developers commit directly to the main branch or very short-lived branches.
  • Relies heavily on automated tests to prevent breaking changes.

💡 When to use: Teams practicing continuous integration and delivery (CI/CD).

2. Follow Clear Branch Naming Conventions

Consistent branch names make it easier to track work.

Recommended Patterns:

  • feature/<short-description> – for new features
  • bugfix/<issue-id> – for bug fixes
  • hotfix/<short-description> – for urgent production fixes
  • release/<version> – for release preparations

Example:

git checkout -b bugfix/issue-1023-login-error

3. Keep Branches Short-Lived

Long-running branches increase the risk of merge conflicts and outdated code.
Best practice is to merge within a few days of starting work.

💡 Regularly sync with the base branch:

git fetch origin
git rebase origin/main

4. Use Pull Requests (PRs) for Collaboration

Pull requests are essential for reviewing code before merging.
They help:

  • Catch bugs early
  • Share knowledge within the team
  • Maintain code quality

PR Best Practices

  1. Small PRs – Easier to review and test
  2. Clear Descriptions – State the “why” and “what”
  3. Link Issues – Connect PRs to tracked issues or tickets
  4. Self-Review First – Fix obvious mistakes before requesting approval

Example PR Description:

### Summary
Added login page with authentication API integration.

### Changes
- Created Login component
- Integrated JWT-based API auth
- Added form validation

### Related Issue
Closes #1023

5. Define Approval Rules

Set repository rules to ensure changes are reviewed before merging:

  • Require at least 1–2 approvals before merge
  • Use code owners for specialized areas of the codebase
  • Enforce status checks (CI/CD tests must pass)

💡 On GitHub: Settings → Branches → Branch Protection Rules

6. Avoid Direct Commits to Main Branch

All changes should go through PRs to ensure peer review and automated testing.
You can enforce this via branch protection rules.

7. Keep Your Commit History Clean

Before merging, use squash or rebase to clean up unnecessary commits.

git rebase -i main

Why?

  • Easier to navigate commit history
  • One commit per logical change

8. Automate Where Possible

Use CI/CD pipelines to:

  • Run tests automatically on each PR
  • Check code formatting and linting
  • Deploy only after approvals

Example tools: GitHub Actions, GitLab CI, CircleCI

Conclusion

By combining clear branching strategies with structured approval processes, you:

  • Reduce merge conflicts
  • Maintain higher code quality
  • Improve collaboration across the team

In short, branch smart, review thoroughly, and automate often — and your Git workflow will stay clean, efficient, and reliable.

Frequently Asked Questions

How long should a feature branch live?

Ideally hours to a couple of days. Long-lived branches drift from main and cause large, conflict-prone merges.

How many reviewers should a pull request require?

One informed reviewer is enough for most changes. Require two only for high-risk areas such as auth, billing or infrastructure.

Should I allow direct commits to the main branch?

No. Protect main with a branch protection rule that requires pull requests and passing status checks.

What is a good branch naming convention?

A short type prefix plus a ticket or description, for example feature/1234-add-login or fix/null-pointer-on-checkout.

You Might Also Like

Related guides