Git Workflow and Team Collaboration Standards

“There’s a merge conflict, who can take a look?”—a line heard in many teams’ weekly meetings. The problem isn’t Git; it’s the lack of a clear Git workflow and team collaboration standard. This article walks through three mainstream workflows, an actionable branching convention, and the bottom-line rules for code review.

1. Three Mainstream Git Workflows Compared

For the vast majority of small and mid-sized teams, GitHub Flow is enough: main is always deployable; each change opens a feature branch; merge after CI passes and review approves. Simple, clear, traceable.

2. Branch and Naming Conventions

Consistent naming saves enormous communication cost. Recommended format:

/-

# Examples
feature/PROJ-123-add-login
fix/PROJ-456-search-bug
chore/PROJ-789-upgrade-deps

• type: feature/fix/chore/docs/refactor/perf.
• issue-id: The ticket number in your task system.
• short-desc: A verb or noun phrase, hyphen-separated.

3. Commit Message Conventions

Adopt Conventional Commits to keep history readable and auto-generate changelogs:

(): 

Example:

feat(auth): add email code login

- Support email + verification code
- Code expires in 5 minutes
- Rate limit: one per email per minute

Closes PROJ-123

Common types: feat/fix/docs/style/refactor/perf/test/chore/build/ci.

4. Merge Strategy: rebase or merge?

This is a frequent debate. A practical suggestion:

• Local sync with upstream: use rebase for a cleaner history.
• Merging feature into main: use squash merge—one change, one commit.
• Multi-person doc branches: use merge to preserve collaboration traces.

Drop a .git-blame-ignore-revs at the repo root to exclude formatting commits from blame, making code ownership clearer.

5. Bottom-Line Rules for Code Review

1. Every change needs at least one reviewer; core modules need two.
2. CI must be fully green before merging; no bypassing.
3. Review three things: is the logic right, are tests complete, is it readable.
4. Suggestions, not directives: comments should propose with reasons, not “change it to this.”
5. 24-hour response: review requests get a response within 24 hours.

6. Protect main: CI and Branch Protection

People alone aren’t enough; you need automated red lines. Recommended config:

• main branch disallows direct push.
• Pre-merge CI must run: lint, unit tests, build, sampled E2E.
• Key branches require both review approval and status check.
• Historical commits require signing (GPG/Sigstore) to prevent impersonation.

A minimal GitHub Actions CI sample:

name: CI
on: [pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint
      - run: npm run test
      - run: npm run build

7. Common Pitfalls

• Large files in the repo: A mistaken upload of a multi-MB image bloats the repo forever. Use LFS or forbid commits.
• Committed secrets: Pushing .env requires git-filter-repo to clean history and rotating keys.
• Long-lived feature branches: A week unmerged and conflicts explode. Cap feature lifespan at three days.
• No .gitignore: node_modules and .DS_Store pollute the repo. Set it up at project init.

8. Summary

Git workflow isn’t a tooling issue; it’s a team contract. Pick a model that reaches quick consensus (GitHub Flow first), and lock down four things—naming, commit messages, review, and CI—then iterate as the team grows. The best standard isn’t the most advanced one, but the one the whole team can consistently follow. When conflicts and finger-pointing drop, people truly believe “code is built collaboratively,” not just “I committed it.”