Professional Git Workflows
Apply Git effectively in real engineering teams using trunk-based development, GitFlow concepts, commit conventions, protected branches, and CI.
Trunk-Based Development
Trunk-based development keeps developers close to a shared main branch. Changes are integrated frequently, often through short-lived branches or directly behind appropriate safeguards. Feature flags can separate code deployment from feature activation.
The goal is to reduce long-running divergence and integration complexity.
- Keep branches short-lived.
- Integrate frequently.
- Use feature flags when incomplete code must be deployed safely.
What is a key characteristic of trunk-based development?
GitFlow and Release Branching
GitFlow is a branching model that traditionally uses branches such as main, develop, feature branches, release branches, and hotfix branches. It can work well for products with structured release cycles, but many modern teams prefer simpler trunk-based workflows.
The important lesson is not to follow a branching model mechanically. Choose the simplest workflow that fits deployment, release, and compliance requirements.
- GitFlow is a workflow convention, not a Git feature.
- Release-heavy products may benefit from dedicated release branches.
- Simpler teams often benefit from trunk-based development.
Is GitFlow built into Git as a special Git mode?
Commit Message Quality
Good commit messages make repository history useful. A practical convention is to use a short imperative subject and add a body when context is required. Teams may adopt Conventional Commits such as feat: add login validation, fix: handle expired token, and docs: update setup guide.
The exact convention matters less than consistency and clarity.
git commit -m "feat: add password reset flow"
git commit -m "fix: reject expired access tokens"
git commit -m "docs: clarify local development setup"- Commit messages should describe intent.
- Consistent conventions improve history search and release automation.
- Avoid vague messages such as
update,changes, orstuff.
Which is the strongest commit message?
Protected Branches and CI
Production repositories commonly protect important branches. Protection can require pull requests, successful CI checks, reviews, signed commits, or status checks before integration.
CI should validate important properties such as tests, linting, type checking, security scanning, and build success. Local hooks improve developer feedback but should not be the only enforcement mechanism.
- Protected branches reduce accidental direct changes.
- CI provides centralized and repeatable validation.
- Server-side checks are more reliable than relying only on local hooks.
Why should critical checks also run in CI if pre-commit hooks already exist?