| English | 中文 |
Branches are used to isolate tasks, and merging is used to bring validated changes back to the main line.
Good branching habits can reduce conflicts, minimize unrelated changes, and make PRs easier to review.
This article uses <integration-branch> for the team’s actual integration branch. It may be named main, master, or develop; replace it according to repository rules.
Create a branch for each independent task:
Create a branch:
git switch -c feat/my-task
Switch back to the main branch:
git switch <integration-branch>
feat/github-governance-guide
fix/recover-lost-commit-example
docs/ai-native-git-workflow
hotfix/remove-broken-link
ai/review-large-repo-guide
For more templates, see Branch Naming Convention.
Before merging, first check. git status --porcelain must print nothing; if there are pending edits, preserve the state instead of switching to the integration branch or merging:
git status --porcelain
git diff --stat <integration-branch>...HEAD
git log --oneline <integration-branch>..HEAD
Confirm that:
Retains the branch integration history, suitable for teams that need to audit the merge context.
git switch <integration-branch>
git merge --no-ff feat/my-task
Squashes multiple commits in a PR into a single commit, suitable for keeping the main branch history clean.
Reapplies the commits in the PR on top of the target branch, suitable for teams pursuing a linear history.
The merge strategy should be unified according to team conventions, rather than chosen based on personal preference.