Our Git Workflow at the Agency

Git is the backbone of any professional software development — but Git alone is not a workflow. How a team handles branches, how commits are structured and how code reviews run makes the difference between a repository that creates clarity and one that turns into a black box. What has proven itself is a clear workflow that provides as much structure as necessary — and no more than a project actually needs.

Our basic principle: main is always deployable. In client projects we work by this rule: no committing directly to main, no half-finished changes, no “just real quick” fixes without a branch. That sounds strict, but it keeps the state of production from becoming unclear — and it has saved us more than once from accidentally pushing unfinished features to the live environment.

Feature Branches and Commit Conventions

Every new feature, every bug fix and every larger change gets its own branch. Naming follows a simple scheme: feature/short-description, fix/what-gets-fixed, chore/what-gets-cleaned-up. That makes it clear at a glance what it’s about — both in the repository and in team communication. Branches are kept small: one branch, one task. Large branches with many changes are hard to review and hard to merge.

For commits, Conventional Commits are a good fit — a standardized format that starts with a type: feat:, fix:, docs:, refactor:, chore:. The advantage: the Git history tells you immediately what kind of change was made. That makes it easier to generate changelogs automatically and helps with debugging, when you want to understand when and why a particular change in behavior was introduced.

Code Reviews as a Learning Opportunity

Pull requests are reviewed by at least one other person before they are merged into main. That is not a formality — it’s one of the most valuable learning processes on the team. A good review doesn’t just comment on mistakes; it asks questions, suggests alternatives and explains the context. Reviews work best when seen as a conversation, not an exam. That lowers the barrier to commenting openly and leads to better code quality.

• main is always deployable — no direct commits in client projects
• Feature branches: small, focused, well named
• Conventional Commits for a readable Git history
• Pull requests always with at least one review
• Automated tests and linting as a mandatory step before the merge

This workflow is not dogma — it’s a foundation that we adapt as needed. For very small projects with little concurrency, the overhead can be reduced. For larger teams or more complex deployments, more structure is needed. But the principles — clarity, traceability, quality control — always stay the same.