Branching Workflows and Code Review

Introduction

Git does not tell a team how to use branches. A workflow is an agreement. A good one reduces conflicts, keeps the main branch working and makes releases boring, which is a good thing.

Common workflows

GitHub flow (simple, popular)

1. main is always deployable.
2. Create a short-lived branch for each change.
3. Open a pull request, get review and passing tests.
4. Merge into main and deploy.

Trunk-based development

Everyone commits to main (the trunk) in very small steps, or via branches that live for hours rather than days. Unfinished features are hidden behind feature flags. It suits teams with strong automated testing and fast releases.

Git flow (heavier)

Long-lived develop and release branches, plus feature and hotfix branches. It fits software with scheduled versions, such as installed apps, but adds overhead for web services that deploy continuously.

Pick the simplest workflow that fits your release process, and keep branches short-lived. The longer a branch lives, the more painful the merge.

Branch protection

On platforms such as GitHub you can protect main:

• Require a pull request before merging
• Require approvals from reviewers
• Require status checks, such as passing tests, to succeed
• Block force pushes and deletion

This makes the safe path the easy path.

Pull requests that are easy to review

• Keep them small, focused on one change
• Write a clear title, and a description of what and why
• Link the issue or task
• Add screenshots for visual changes
• Make sure tests and checks pass before asking for review
• Keep commit messages clear. Many teams use a style such as feat: add search or fix: handle empty cart (conventional commits).

Merge methods

When merging a pull request, teams usually choose:

• Merge commit: keeps every commit and the branch shape
• Squash and merge: combines the branch into one commit on main, giving a tidy history
• Rebase and merge: replays commits linearly

Reviewing well

As a reviewer: be kind and specific, ask questions, explain why, and separate must-fix issues from preferences. Praise good work too. As an author: do not take it personally, respond to every comment, and say thanks. Review the code, not the person.

Try it yourself

Write down how your team or project would branch and merge, in five lines. Then draft a pull request description for a recent change with "what", "why" and "how I tested".

Summary

• GitHub flow, trunk-based development and Git flow trade simplicity against structure. Keep branches short.
• Protect main with required reviews and passing checks.
• Small, well-described pull requests and kind, specific reviews keep teams fast.