Git 分支开发完成后，最佳实践是通过远程仓库的 Pull Request（或 Merge Request）流程合并到 master 分支，适用于团队协作场景，直接本地合并推送会绕过代码审查和自动化检查。
先说结论：团队开发中必须使用 Pull Request 机制合并代码，禁止直接 push 到 master 分支。
- 适合：多人协作、需要代码审查、有 CI/CD 流水线的項目
- 先看：本地分支是否已同步远程 master 最新代码
- 建议：合并后删除已完成的特性分支，保持仓库整洁
命令速用版
本地准备合并前的同步与推送命令，后续需在网页端完成审查合并。
git checkout master
git pull origin master
git checkout feature-branch
git merge master
git push origin feature-branch为什么会这样
直接本地合并推送会跳过团队约定的质量门禁。Pull Request 流程强制要求代码经过他人审查和自动化测试通过后才合入主干，降低生产环境故障风险。
分步处理
1. 同步主干代码：切换至 master 分支并拉取远程最新提交，确保基于最新状态开发。
2. 合并主干到特性分支：在特性分支上合并 master，解决潜在冲突，避免合并到 master 时出现意外。
3. 推送特性分支：将本地特性分支推送到远程仓库，作为创建合并请求的基础。
4. 创建合并请求：在 GitHub 或 GitLab 网页端新建 Pull Request，指定目标分支为 master。
5. 完成审查与合并：待 CI 检查通过且同事审查批准后，在网页端点击合并按钮。
怎么验证是否生效
查看远程仓库 commit 历史确认新提交已出现在 master 分支，且 CI/CD 流水线状态显示成功。
常见坑
1. 强制推送：严禁对公共分支使用 git push -f，会覆盖他人提交。
2. 冲突未解：本地合并冲突未解决就直接推送，导致远程仓库状态异常。
3. 大文件提交：误将编译产物或敏感配置提交到仓库，增加克隆体积或泄露风险。
常见问题
合并时应该用 merge 还是 rebase？
公共分支合并建议用 merge 保留历史上下文，个人提交整理可用 rebase 保持线性历史。
合并完成后需要删除分支吗？
建议删除已合并的特性分支，避免仓库分支列表冗余，远程分支可在 PR 页面勾选自动删除。
master 分支被保护无法推送怎么办？
这是正常保护机制，必须通过 Pull Request 流程申请合并，不能直接 push 代码。
如何撤销错误的合并提交？
使用 git revert 命令生成反向提交来撤销更改，不要直接使用 reset 重置公共分支历史。
参考来源
1. Git SCM - Pro Git Book: Git 分支 - 分支的工作流程 (https://git-scm.com/book/en/v2)
2. GitHub Docs - About pull requests (https://docs.github.com/en/pull-requests)
3. Atlassian Git Tutorial - Git Workflows (https://www.atlassian.com/git/tutorials/comparing-workflows)