my-git

Feature Branch Workflow

English

中文

Feature Branch Workflow is the most straightforward collaboration model for most teams to adopt.

Its core principle is: develop every feature or fix in an independent branch, and merge it into the main branch via a PR when complete.

Process

<integration-branch> -> feature branch -> pull request -> review -> CI -> merge

<integration-branch> denotes the team’s actual integration branch, such as main, master, or develop.

Suitable Scenarios

• Parallel development with multiple people
• Medium to large business systems
• Teams requiring review and CI
• Teams not yet ready for full Trunk-Based Development
• Requirements can generally be broken down into independent tasks

Branch Recommendations

feat/user-login
fix/payment-timeout
docs/git-workflow-guide
refactor/order-validator

Branch names should express the intent of the task; avoid names like test, tmp, or new.

PR Recommendations

• One PR solves only one problem
• Separate behavioral changes and refactoring as much as possible
• PR descriptions should clearly state validation methods
• Risky changes should clearly outline fallback plans
• Delete branches promptly after merging

Things to Note

1. Branches should not be long-lived

The longer a branch exists, the more it diverges from the main branch, making merge conflicts harder to resolve.

2. Sync with the main branch regularly

Before synchronizing, confirm that the current feature branch has no other pending edits, that collaborators have not based work on local commits, and that team rules allow a rebase.

git status --porcelain
git fetch origin
git rebase origin/<integration-branch>

Whether to use rebase depends on team conventions.

3. Avoid large PRs

If a PR is already hard to review, break it down first.

Extended Reading

• Atlassian: Feature Branch Workflow
• Pull Request Best Practices
• Code Review Best Practices
• Recommended Reading Index

This site is open source. Improve this page.