5 Git Workflows That Will Make Your Team More Productive

Git is ubiquitous. Git discipline is rare. These five workflows are low-friction and high-payoff.

1. GitHub Flow (For Most Teams)

One main branch. All work in short-lived feature branches. Merge via pull request.

git checkout -b feature/user-authentication
# ... work ...
git push origin feature/user-authentication
# Open a PR → review → merge → delete branch

Rules:

• main is always deployable
• Branches live for days, not weeks
• Every merge goes through a PR with at least one reviewer
• Delete branches after merge

[!TIP] Enforce "Require branches to be up to date before merging" in GitHub branch protection settings. This prevents the class of bugs where a feature branch doesn't have recent changes from main.

2. Conventional Commits

Structure your commit messages. Unlocks automated changelogs and semantic versioning.

feat: add QR code WiFi mode support
fix: correct JSON parser crash on empty arrays
docs: update README with environment variables
chore: upgrade next.js to 16.0.10
perf: lazy-load tool components on route change
refactor: extract heading parser to server utility

Format: type(optional-scope): description

Types: feat, fix, docs, style, refactor, perf, test, chore, ci

Why it matters: tools like semantic-release and standard-version read commit messages and automatically bump version numbers and generate CHANGELOG.md entries.

npm install -g commitizen
# Then use 'git cz' instead of 'git commit' for a guided prompt

3. Squash Merging for Clean History

Instead of merging every commit from a feature branch, squash them into one:

# In GitHub: "Squash and merge" button
# On CLI:
git checkout main
git merge --squash feature/my-feature
git commit -m "feat: add email signature templates"

Before squash:

* wip
* trying again
* fix typo
* oops
* working now

After squash:

* feat: add email signature templates

[!NOTE] Squash merging means you lose granular commit history on the feature branch. Keep branches short so this isn't a problem — if a branch has 40 commits, something went wrong earlier.

4. Interactive Rebase Before PR

Clean up your commits before asking for review:

git rebase -i HEAD~5  # Interactively edit last 5 commits

In the editor:

pick a1b2c3 feat: add email template base
squash d4e5f6 fix typo in template
squash g7h8i9 wip
pick j0k1l2 feat: add template preview

squash merges that commit into the previous one. The result: a clean, logical history that's easy to review and bisect.

5. Branch Protection Rules

Set these in GitHub → Settings → Branches → Branch protection rules for main:

✅ Require a pull request before merging
✅ Require approvals: 1
✅ Dismiss stale pull request approvals when new commits are pushed
✅ Require status checks to pass before merging
    → Your CI pipeline: lint, typecheck, test
✅ Require branches to be up to date before merging
✅ Restrict who can push to matching branches
✅ Do not allow bypassing the above settings

This prevents accidental direct pushes to main and ensures every change is reviewed and CI-green before landing.

Putting It Together

A workflow that scales:

# Start work
git checkout main && git pull
git checkout -b feat/new-feature

# Work in small logical commits
git add -p  # Add hunks interactively, not entire files
git commit -m "feat: initial structure for new feature"

# Before opening PR
git rebase -i HEAD~4  # Clean up commits
git push origin feat/new-feature

# After review
# Use "Squash and merge" on GitHub
# Delete the branch

The goal is a main branch history that reads like a table of contents: each entry is a meaningful unit of work, described in plain English, that any team member can understand.