What is the best Git workflow for a small team?

The feature branch workflow is ideal for teams of 2-5 developers. Each developer creates a branch for their feature or fix, pushes it to the remote, opens a pull request for code review, and merges into main after approval. It's simple enough to learn quickly but structured enough to prevent chaos.

Should small teams use Git Flow or GitHub Flow?

For most small teams, GitHub Flow (or a simplified feature branch workflow) is better than Git Flow. Git Flow adds complexity with develop, release, and hotfix branches that small teams rarely need. GitHub Flow keeps things simple: branch from main, work, open a PR, merge back to main.

How should we name our Git branches in a team?

Use a consistent prefix convention: feature/ for new features, bugfix/ for bug fixes, and hotfix/ for urgent production fixes. Follow with a short, descriptive name using hyphens: feature/user-login, bugfix/cart-total, hotfix/security-patch. This makes it easy to see what each branch is about at a glance.

How do we prevent merge conflicts in a small team?

Communicate about who is working on what, keep branches short-lived (merge within 1-2 days), pull from main frequently to stay in sync, and avoid having multiple people edit the same files simultaneously. When conflicts do happen, resolve them on your feature branch before opening a PR.

Should we protect the main branch even in a small team?

Yes, protecting main is one of the most important practices even for a team of two. Require at least one code review before merging, disable direct pushes to main, and optionally require CI checks to pass. This catches bugs early and ensures everyone on the team understands the codebase.

Git Workflow for Small Teams: a practical guide

A simple, proven Git workflow for teams of 2-5 developers. Feature branches, pull requests, code reviews, and branch protection — everything you need to collaborate without stepping on each other's toes.

Practice team workflows Git glossary

gitquest — enquête

The feature branch workflow

The simplest and most effective workflow for small teams. Every change gets its own branch, a review, and a clean merge into main.

Branch

Create a new branch from main for each feature or fix.

Commit

Make small, focused commits with clear messages describing the change.

Review

Push and open a pull request. A teammate reviews your code before merging.

Merge

After approval, merge into main and delete the branch.

Convention

Branch naming conventions

Consistent branch names make it instantly clear what each branch is for. Agree on a convention and stick to it.

`feature/`

New functionality or enhancement.

feature/user-loginfeature/dashboard-charts

`bugfix/`

Non-urgent bug fixes found during development.

bugfix/cart-total-roundingbugfix/email-validation

`hotfix/`

Urgent production fixes that can't wait.

hotfix/security-patchhotfix/login-crash

Full team workflow in the terminal

From cloning to merging — a complete collaboration cycle.

1. Clone & branch

gitquest — branch

# Clone the project and create a feature branch

$git clone git@github.com:team/webapp.git

Cloning into 'webapp'...

done.

$cd webapp

$git checkout -b feature/user-authentication

Switched to a new branch 'feature/user-authentication'

# Work on your feature, then stage and commit

$git add src/auth.ts src/login.tsx tests/auth.test.ts

$git commit -m "feat: add user authentication flow"

[feature/user-authentication a3b4c5d] feat: add user authentication flow

3 files changed, 147 insertions(+)

2. Push & pull request

gitquest — push

# Push your branch to remote

$git push -u origin feature/user-authentication

Enumerating objects: 8, done.

Counting objects: 100% (8/8), done.

To github.com:team/webapp.git

* [new branch] feature/user-authentication -> feature/user-authentication

# Create a pull request for code review

$gh pr create --title "feat: user authentication" --body "Adds login/signup flow"

Creating pull request for feature/user-authentication into main

https://github.com/team/webapp/pull/42

3. Handle merge conflicts

gitquest — merge

# Before merging, sync with main to catch conflicts early

$git checkout main

$git pull origin main

Already up to date.

$git checkout feature/user-authentication

$git merge main

CONFLICT (content): Merge conflict in src/app.tsx

Automatic merge failed; fix conflicts and then commit the result.

# Resolve the conflict in your editor, then:

$git add src/app.tsx

$git commit -m "fix: resolve merge conflict in app.tsx"

[feature/user-authentication d5e6f7a] fix: resolve merge conflict in app.tsx

Pull requests and code reviews

Good PR habits

Keep PRs small and focused — one feature or fix per PR

Write a clear description explaining what changed and why

Include screenshots or test results when relevant

Respond to review comments promptly to keep momentum

Good review habits

Review within 24 hours — don't block your teammates

Be constructive and specific in your feedback

Check for logic errors, edge cases, and naming clarity

Approve when it's good enough — don't aim for perfection

Essential rule

Protect the main branch

Even in a team of two, never push directly to main. Branch protection is your safety net against accidental breakage.

What to enable

Require at least 1 approval before merging. Block direct pushes to main. Optionally require CI/CD checks to pass before the merge button becomes available.

Why it matters

A broken main branch blocks the entire team. Code reviews catch bugs that the author missed, spread knowledge across the team, and keep code quality consistent.

Part of the Remote & Collaboration guide

GitQuest is created by Anaïs (nouvelle fenêtre), web developer and head of education, specializing in tech training and digital accessibility.

Questions about team Git workflows

Practice team workflows in a safe terminal

GitQuest investigations simulate real team collaboration scenarios with remote repositories and merge conflicts.

Start the investigations