Git Workflows Every Developer Should Know

Why Workflow Matters More Than Commands

Most developers learn Git commands before they learn Git workflows. This creates teams where everyone knows how to commit and push, but nobody agrees on how to structure branches, handle releases, or review code. A shared workflow is the difference between a manageable codebase and a spaghetti of conflicting branches.

Feature Branch Workflow

The simplest useful workflow: every new feature or bug fix gets its own branch off main. When the work is ready, open a pull request, get a review, and merge. The main branch always reflects deployable code.

This works well for small teams and is the baseline most other workflows build on. The key discipline is keeping feature branches short-lived — ideally merged within a day or two — to minimize merge conflicts.

git checkout -b feature/user-auth
# ... work ...
git push origin feature/user-auth
# open pull request on GitHub

Gitflow

Gitflow introduces a develop branch alongside main. Feature branches merge into develop, which accumulates changes until a release branch is cut. The release branch goes through QA, then merges to both main and develop. Hotfixes branch directly from main.

Gitflow suits products with scheduled release cycles and parallel version maintenance. It is overkill for continuous-delivery web apps, where trunk-based development is a better fit.

Trunk-Based Development

Trunk-based development (TBD) is the workflow used by Google, Facebook, and most high-velocity teams. Everyone commits to a single trunk branch (usually main) multiple times per day. Feature flags hide incomplete work from users. There are no long-lived branches.

TBD requires strong CI: every commit triggers a full test suite, and broken builds block merges. When it works, it produces the fastest feedback loops and the lowest merge conflict rate of any workflow.

Squash, Merge, or Rebase?

When merging a pull request, you have three options. Merge commit preserves the full branch history — useful when you want to see exactly which commits composed a feature. Squash and merge collapses all branch commits into one, keeping the main branch history clean. Rebase and merge replays commits on top of main, producing a linear history without a merge commit.

Choose one strategy per repository and enforce it consistently. Mixing strategies makes git log and git bisect confusing.

Commit Message Conventions

Adopt Conventional Commits: prefix messages with a type like feat:, fix:, docs:, chore:, or refactor:. This makes automated changelog generation possible and makes git log --oneline readable at a glance. The subject line should complete the sentence "If applied, this commit will..." in 50 characters or fewer.