Skip to content

Git for Teams: Workflows, Conventions and Best Practices

DodaTech Updated 2026-06-22 5 min read

In this tutorial, you'll learn about Git for Teams: Workflows, Conventions and Best Practices. We cover key concepts, practical examples, and best practices.

Team Git conventions are agreed-upon rules for commit messages, branch naming, and code review that reduce friction and make project history readable.

In this tutorial, you'll learn how to establish Git conventions and workflows that make team collaboration smooth and predictable. Without conventions, teams face inconsistent commit messages, confusing branch names, merge conflicts, and miscommunication. By the end, you'll implement commit conventions, branch naming, code review workflows, and automation that keeps your team aligned.

flowchart TD
  A[Team conventions] --> B[Branch naming]
  A --> C[Commit messages]
  A --> D[Pull request workflow]
  A --> E[Code review process]
  B --> F[feat/login, fix/payment, chore/ci]
  C --> G[feat(auth): add OAuth support]
  D --> H[Branch -> PR -> Review -> Merge]
  E --> I[At least 1 approval, no self-merge]

Commit Message Convention

Adopt the Conventional Commits specification:

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

[optional body]

[optional footer]

Types:

Type Meaning Example
feat A new feature feat(login): add OAuth2 support
fix A bug fix fix(payment): handle null amount
docs Documentation changes docs(readme): update installation
style Code formatting only style(app): format with prettier
refactor Code change with no feature/fix refactor(api): extract validation
test Adding or fixing tests test(auth): add login test cases
chore Build/tooling changes chore(deps): upgrade node to 18

Branch Naming Convention

Consistent branch names make project navigation easier:

<type>/<short-description>

Examples:

  • feat/user-authentication
  • fix/payment-null-pointer
  • chore/update-dependencies
  • docs/api-reference
  • refactor/database-layer

Pull Request Workflow

Standard PR workflow:

  1. Create branch from main
  2. Make changes and commit
  3. Push branch and open PR
  4. Request review from team
  5. Address review feedback
  6. Merge (squash or merge commit)
  7. Delete branch

PR description template:

## What does this PR do?
[Brief description]

## Related Issue
Closes #[issue number]

## Checklist
- [ ] Tests added/updated
- [ ] Documentation updated
- [ ] Code follows style guide
- [ ] Self-review completed

Code Review Best Practices

Do Don't
Review within 24 hours Let PRs sit for days
Explain reasoning in comments Leave vague "fix this"
Review in batches of <400 lines Review massive PRs
Suggest alternative approaches Demand changes without discussion
Acknowledge good code Only comment on negatives
Use GitHub suggestion feature Leave non-actionable feedback

Automation for Teams

Protect branches with rules:

Rule Purpose
Require pull request before merging Prevent direct pushes
Require at least 1 approval Ensure code review
Require status checks Block failing builds
Require linear history Clean commit graph
Include administrators No exceptions

Use GitHub Actions to enforce conventions:

name: Enforce Commit Convention
on: pull_request
jobs:
  check-commit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check commit messages
        run: |
          git log --format=%s ${{ github.event.pull_request.base.sha }}..HEAD |
          while read msg; do
            if ! echo "$msg" | grep -qE "^(feat|fix|docs|style|refactor|test|chore)(\(.+\))?: .+"; then
              echo "Bad commit: $msg"
              exit 1
            fi
          done

Common Errors

Error Cause Fix
Inconsistent commit messages No convention enforced Add commit-msg hook or CI check
Merge conflicts due to long-lived branches Branches not synced Daily rebase on main
PR too large for review Too many changes in one PR Enforce 400-line PR limit
Merged without review No branch protection Add required reviews in settings
fixup! commits in history Interactive rebase leftovers git rebase -i to squash
Wrong branch merged Branch naming not clear Enforce naming convention
Secrets committed No pre-commit hooks Add secret scanning to CI
No linear history Merge commits allowed Require squash merging

Practice Questions

What is the Conventional Commits specification?

Conventional Commits is a specification for commit messages that uses structured prefixes like feat:, fix:, docs:. It enables automated version bumps (via semantic-release), changelog generation, and clear communication of commit intent. The format is type(scope): description.

Why is branch naming important for teams?

Consistent branch naming (e.g., feat/login, fix/payment) makes it clear what each branch does at a glance. It helps CI/CD systems apply branch-specific rules, simplifies branch cleanup, and reduces confusion about which branch to review or merge.

What is branch protection and why use it?

Branch protection prevents direct pushes to important branches (usually main). It enforces rules like requiring pull request reviews, passing status checks, and linear history. Protection ensures no code reaches production without review and testing.

How do I enforce commit conventions on my team?

Use a combination of (1) a commit-msg Git hook that validates message format locally, (2) a CI check that runs on pull requests to verify all new commits follow the convention, and (3) a squashing merge strategy that lets you rewrite messages at merge time.

What is the ideal PR size for code review?

Research shows that code review effectiveness drops significantly above 400 lines changed. Small PRs (under 200 lines) are reviewed faster and find more bugs. Encourage teams to make smaller, focused PRs by breaking features into logical chunks

Challenge

Design a complete Git convention document for a team of 8 developers. Include: commit message format (Conventional Commits), branch naming convention, PR workflow steps, code review guidelines (with time expectations), branch protection rules, and automation checks. Write this as a CONTRIBUTING.md file.

Real-World Task

Set up a new repository with full team workflow automation. Configure branch protection on main requiring PRs, one approval, and passing CI. Create issue and PR templates. Add a CI workflow that lints code and validates commit messages. Add a CODEOWNERS file for team review assignments. Finally, enforce squash merging with Conventional Commits. This complete setup mirrors the standard DodaTech project template used for all internal tools.


Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro