Git: Professional Team Workflow

Gitflow, trunk-based development, conventional commits and everything you need to collaborate effectively.

Gitflow or Trunk-based?

This is the first question you need to answer with your team. There’s no universal answer — it depends on how you deploy.

Gitflow makes sense when:

You have scheduled releases (every 2 weeks, every month)
Multiple versions in production simultaneously
Large teams with separate QA

Trunk-based development makes sense when:

Continuous deployments (multiple times a day)
Feature flags to hide work in progress
Teams that value frequent integration

The modern trend in agile teams is trunk-based. Frequent integration into the main branch catches conflicts before they become problems.

Conventional Commits

Standardizing commit messages transforms the git history into useful documentation:

type(scope): short description

[optional body]
[optional footer]

Main types:

feat: new feature
fix: bug fix
docs: documentation only
refactor: refactoring without behavior change
chore: maintenance tasks (deps, config)
test: tests
perf: performance improvements

# Good messages:
git commit -m "feat(auth): add JWT refresh token rotation"
git commit -m "fix(api): handle null user in session middleware"
git commit -m "chore: update dependencies to latest"

# Bad messages:
git commit -m "fix stuff"
git commit -m "wip"
git commit -m "asdfgh"

With conventional commits you can auto-generate changelogs and automatically determine whether a release is major, minor or patch.

Branch Strategy

For trunk-based with CI/CD:

main          → Production. Always deployable.
feat/xxx      → Short features (max 2-3 days lifespan)
fix/xxx       → Bug fixes
chore/xxx     → Maintenance

Feature branches should be short. If you’ve been on a branch for more than 3 days without merging, you’re probably working on something too large that should be split up.

Effective Pull Requests

A good PR:

One single thing — don’t mix feature + refactor + bugfix
Description of the why, not just the what
Screenshots for UI changes
Tests covering the new behavior

Suggested template:

## What changes?
- Brief description of the changes

## Why?
- Motivation or issue it solves

## How to test
1. Step 1
2. Step 2

## Screenshots (if applicable)

Commands Every Dev Should Master

# View history as a tree
git log --oneline --graph --all

# Undo the last commit (keeps the changes)
git reset --soft HEAD~1

# Bring specific changes from another branch
git cherry-pick <commit-hash>

# Interactive rebase (clean up commits before PR)
git rebase -i HEAD~3

# Stash changes temporarily
git stash push -m "wip: feature login"
git stash pop

# Find which commit introduced a bug
git bisect start
git bisect bad           # current commit has the bug
git bisect good v1.0.0   # this tag was fine
# git bisect guides you automatically

Main Branch Protection

Configure these rules in GitHub/GitLab:

Require PR reviews before merge (minimum 1 reviewer)
Require status checks — CI must pass
No force push to main
Delete branches automatically after merge

Conclusion

A good Git workflow isn’t about which strategy you use — it’s about consistency, frequent integration and clear communication through commits. Start with conventional commits and small PRs; the rest follows naturally.