Git Workflow

Why teams need a shared workflow

Git itself imposes almost no rules. You can commit directly to main, name branches anything, and merge whenever you like. That freedom is fine for a solo project, but the moment two or more people touch the same repository, chaos follows without agreement on how branches are created, named, reviewed, and merged. A workflow is simply that agreement, written down and followed consistently.

The feature branch workflow

The most common convention in professional teams is the feature branch workflow. Instead of committing new work directly to main, every piece of work — a feature, a bug fix, a refactor — gets its own branch created off the latest main. Work happens in isolation on that branch, and main stays deployable at all times because nothing lands there except reviewed, finished work.

• Create a branch from an up-to-date main before starting any task.
• Commit small, focused changes with descriptive messages as you go.
• Push the branch to the remote regularly so work is backed up and visible.
• Open a pull request when the branch is ready for review.
• Merge into main only after review and passing checks, then delete the branch.

$ git checkout main
$ git pull origin main
$ git checkout -b feature/user-avatar-upload
Switched to a new branch 'feature/user-avatar-upload'

Naming conventions

Branch names are cheap documentation. A consistent prefix tells reviewers and tooling what kind of change to expect before they open a single file. Common prefixes include feature/ for new functionality, fix/ or bugfix/ for defect repairs, chore/ for maintenance work like dependency bumps, and hotfix/ for urgent production patches. Many teams also append a ticket number, such as feature/HYR-482-avatar-upload, so the branch links straight back to the tracker.

$ git push -u origin feature/user-avatar-upload
Total 6 (delta 3), reused 0 (delta 0)
remote: Create a pull request for 'feature/user-avatar-upload' on GitHub by visiting:
remote:   https://github.com/team/repo/pull/new/feature/user-avatar-upload

Commit message discipline

A commit message has two parts that matter: a short summary line under about 50 characters written in the imperative mood ("add", not "added" or "adds"), and an optional body explaining why the change was made, not just what changed — the diff already shows what changed. Many teams adopt Conventional Commits, prefixing messages with feat:, fix:, docs:, or refactor: so changelogs can be generated automatically.

Keeping main protected

Most hosting platforms let you configure branch protection rules on main: requiring at least one approving review, requiring CI checks to pass, and disallowing direct pushes entirely. This turns the social convention of the feature branch workflow into an enforced technical rule, so a rushed commit can never accidentally land in main unreviewed.

$ git push origin main
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci/build" is expected.