Git Best Practices: Commits, Branches & Workflows for Teams

Git is the backbone of modern software development. Nearly every team — from solo freelancers to Fortune 500 engineering departments — uses it daily. Yet the difference between a team that merely uses Git and one that uses it well is enormous. Poor Git hygiene leads to tangled histories, painful merge conflicts, broken builds, and hours of lost productivity. This guide covers the practices, conventions, and workflows that separate professional-grade version control from chaos.

Writing Excellent Commit Messages

A commit message is a letter to your future self (and your teammates). The Git log is often the first place a developer looks when trying to understand why a change was made. Vague messages like fix stuff or update make the log useless.

The Conventional Commits Format

The widely adopted Conventional Commits specification structures messages as follows:

<type>(<scope>): <short description>

[optional body]

[optional footer(s)]

Common types include:

• feat — a new feature
• fix — a bug fix
• docs — documentation changes only
• style — formatting, whitespace (no logic change)
• refactor — restructuring code without changing behavior
• test — adding or updating tests
• chore — build scripts, CI config, dependency bumps
• perf — performance improvements

# ❌ Bad
fix bug
updated styles
misc changes

# ✅ Good
fix(auth): prevent session fixation on login redirect

feat(dashboard): add CSV export for monthly reports

refactor(api): extract validation logic into middleware

chore(deps): bump lodash from 4.17.20 to 4.17.21

The Seven Rules of Great Commit Messages

1. Separate the subject from the body with a blank line.
2. Limit the subject line to 50 characters.
3. Capitalize the subject line.
4. Do not end the subject line with a period.
5. Use the imperative mood ("Add feature" not "Added feature").
6. Wrap the body at 72 characters.
7. Use the body to explain what and why, not how.

Branching Strategies

A branching strategy defines how your team creates, names, and merges branches. The right choice depends on your team size, release cadence, and deployment pipeline.

GitFlow

GitFlow, popularized by Vincent Driessen in 2010, uses long-lived branches:

• main (or master) — always reflects production
• develop — integration branch for features
• feature/* — branched from develop, merged back into develop
• release/* — branched from develop when preparing a release
• hotfix/* — branched from main for urgent production fixes

main ─────●─────────────────●──── (releases)
           \                 /
develop ────●───●───●───●───● ── (integration)
                \       /
feature/login ───●───●─── (feature work)

Best for: Teams with scheduled releases, mobile apps, or products that maintain multiple versions simultaneously.

Trunk-Based Development

In trunk-based development, everyone commits to a single branch (usually main) with short-lived feature branches that last hours or a few days at most:

main ──●──●──●──●──●──●──●──●──  (continuous integration)
        \  /    \  /
         ●─      ●─   (short-lived branches, < 2 days)

Best for: Teams practicing continuous delivery, SaaS products, and organizations with strong automated testing. Google, Facebook, and Netflix use variations of this approach.

GitHub Flow

A simplified model with just main and feature branches. Every change goes through a pull request, gets reviewed, passes CI, and is merged directly to main. This is the sweet spot for most small-to-medium teams.

Rebasing vs. Merging

This is one of the most debated topics in Git. Both achieve the same end result — integrating changes from one branch into another — but they produce very different histories.

Merge Commits

# Creates a merge commit preserving branch topology
git checkout main
git merge feature/login

# History shows the branch and merge point:
*   Merge branch 'feature/login'
|\
| * Add login form validation
| * Create login page component
|/
* Previous commit on main

Rebase

# Replays your commits on top of the target branch
git checkout feature/login
git rebase main

# History becomes linear:
* Add login form validation
* Create login page component
* Previous commit on main

When to Use Each

• Rebase for updating your feature branch with the latest changes from main — keeps history clean.
• Merge for integrating a completed feature branch into main — preserves context.
• Never rebase commits that have been pushed and shared with others — it rewrites history and causes conflicts for teammates.

A popular hybrid approach is "rebase locally, merge to main": rebase your feature branch against main before opening a PR, then use a merge commit (or squash merge) to land it.

Pull Request Best Practices

Pull requests (PRs) are more than a merge mechanism — they are a team communication tool. Here is how to make them effective:

1. Keep PRs small — aim for under 400 lines of diff. Large PRs receive rubber-stamp reviews.
2. Write a clear description — explain what changed, why, and how to test it. Include screenshots for UI changes.
3. Link to the issue — use keywords like Closes #42 to auto-close issues on merge.
4. Request specific reviewers — don't rely on the whole team; assign 1–2 people with relevant context.
5. Respond to all comments — either address the feedback or explain why you disagree.
6. Use draft PRs for work-in-progress to get early feedback without triggering a full review.
7. Require CI to pass before merging — lint, tests, and build checks should be mandatory.

Crafting a Solid .gitignore

A well-configured .gitignore keeps your repository clean by excluding files that should never be tracked:

# Dependencies
node_modules/
vendor/

# Build output
dist/
build/
*.min.js
*.min.css

# Environment & secrets
.env
.env.local
*.pem

# OS files
.DS_Store
Thumbs.db

# IDE files
.vscode/
.idea/
*.swp

# Logs
*.log
npm-debug.log*

Tips:

• Use gitignore.io to generate templates for your stack.
• Never commit secrets, API keys, or credentials. Use environment variables instead.
• Commit lock files (package-lock.json, composer.lock) — they ensure reproducible builds.
• Consider a global gitignore (~/.gitignore_global) for OS and editor files.

Semantic Versioning (SemVer)

If you're publishing libraries, APIs, or packages, Semantic Versioning provides a clear contract with your users. The format is MAJOR.MINOR.PATCH:

Given version 2.4.1:

MAJOR (2) — Increment for breaking/incompatible API changes
MINOR (4) — Increment for new features (backward compatible)
PATCH (1) — Increment for bug fixes (backward compatible)

Examples:
1.0.0 → 1.0.1   Bug fix
1.0.1 → 1.1.0   New feature added
1.1.0 → 2.0.0   Breaking change introduced

Pre-release labels:
1.0.0-alpha.1
1.0.0-beta.3
1.0.0-rc.1

When combined with Conventional Commits, tools like semantic-release and standard-version can automatically determine the next version number and generate changelogs from your commit history. A feat commit bumps the minor version; a fix bumps the patch; and any commit with a BREAKING CHANGE footer bumps the major version.

Git in Your Build Pipeline

Modern CI/CD pipelines are triggered by Git events — pushes, pull requests, and tags. A typical pipeline might:

1. Lint — check code style and formatting.
2. Test — run unit, integration, and end-to-end tests.
3. Build — compile, bundle, and minify assets (JavaScript, CSS, HTML).
4. Deploy — push artifacts to staging or production.

The build step often includes minification of front-end assets. Minified JavaScript and CSS files are significantly smaller, reducing page load times and bandwidth usage. While you should always commit your source files (not minified output), your pipeline should produce optimized builds for deployment.

Common Git Mistakes & How to Fix Them

• Committed to the wrong branch? — Use git stash, switch branches, then git stash pop. Or use git cherry-pick to move the commit.
• Need to undo the last commit? — git reset --soft HEAD~1 keeps your changes staged.
• Accidentally committed a secret? — Remove it with git filter-branch or BFG Repo-Cleaner, rotate the credential immediately, and force-push.
• Merge conflict anxiety? — Pull and rebase frequently to keep your branch close to main. Small, frequent merges produce fewer conflicts than big, infrequent ones.

Conclusion

Good Git practices are a force multiplier. Clear commit messages make debugging faster. A well-chosen branching strategy reduces friction. Thoughtful pull requests catch bugs before they reach production. And automated versioning with SemVer gives your users confidence in your releases. Start with the practices that address your team's biggest pain points, and adopt the rest incrementally — the compound effect on your workflow will be dramatic.