A Git Workflow for a Small Team: Branches, Reviews and Releases

Keep one branch always releasable

Use main as the branch that is always in a deployable state. Work happens on short-lived feature branches created from the latest main. Protect main in your hosting platform so changes arrive only through reviewed pull requests with passing checks. This single rule removes the 'is main broken today?' question.

Keep branches short-lived

Long-running branches drift from main and produce large, painful merges. Aim for branches that last a few days at most. Split big features into smaller pull requests that each leave main working, using feature flags to hide incomplete work from users when necessary.

Update a branch from main regularly. Whether the team prefers merging main into the branch or rebasing the branch onto main is less important than agreeing on one approach and never rewriting history that others share.

Make pull requests easy to review

• Keep each pull request focused on one change; reviewers can examine a few hundred lines carefully but skim a few thousand.
• Write a description that states the problem, the approach and how it was tested, with screenshots for UI changes.
• Shape commits so each is one logical step, separating formatting and renames from behaviour changes.
• Let automated checks run linting, type checking and tests before a human reviews.
• Agree on a review turnaround so pull requests do not wait for days.

Resolve conflicts deliberately

Conflicts happen when two branches change the same lines. Resolve them by understanding both changes, not by picking one side. After resolving, run the tests. Frequent small merges keep conflicts small; if the same files conflict repeatedly, the team may need to agree on ownership or split the module.

Tag releases and write notes

When you deploy, tag the commit, for example v1.4.0, so you can always see exactly what was released and roll back to a known point. Keep a short changelog or release notes generated from pull-request titles. Good titles make this nearly automatic.

git tag -a v1.4.0 -m "Webinar checkout with per-session pricing"
git push origin v1.4.0

Plan for hotfixes

When production needs an urgent fix, branch from the release tag or main, make the smallest possible change, review it quickly but properly and deploy. Then make sure the fix is on main so it is not lost in the next release. Write down the steps once, so the team does not improvise under pressure.

Protect the repository

Never commit secrets; use a .gitignore for environment files and enable secret scanning if your platform offers it. If a secret is committed, rotate it immediately, because removing it from history does not undo the exposure. Require pull requests, passing checks and at least one review on main, and restrict who can force-push.

Checklist

• main is protected and always deployable
• Feature branches are short-lived and updated regularly
• Pull requests are focused and well described
• Automated checks run before review
• Releases are tagged with notes
• Hotfix steps are documented
• Secrets never enter the repository