主分支名需根据远程实际为准，执行git branch -r查看远程分支列表（如origin/main或origin/master），再用git branch确认本地当前分支；硬写master可能导致checkout失败。
先确认主分支名是 main 还是 master
Git 默认主分支名在 2020 年后已逐步从 master 改为 main，但旧仓库或公司规范仍可能用 master。执行 git branch -r 查看远程分支列表，常见的是 origin/main 或 origin/master；本地当前主分支可通过 git branch 看带 * 的那个。别直接硬写 git checkout master ——如果远程只有 main，这步会失败并报错 pathspec 'master' did not match any file(s)。
必须先同步本地主分支再合并
跳过这步是绝大多数“合并后代码丢失”或“PR 显示大量无关提交”的根源。正确顺序是：
- 切换到本地主分支：
git checkout main（或git checkout master） - 拉取远程最新：
git pull origin main（注意分支名要和上一步一致） - 切回你的功能分支：
git checkout feature/login - 再合并主分支进来（可选，用于提前解决冲突）：
git merge main
这一步不是仪式感——它确保你的功能分支基于最新主干，避免后续 git merge feature/login 时把别人已合入的提交又重复带进来。
合并方式选 merge 还是 rebase？看协作场景
git merge 和 git rebase 都能达成“代码进主分支”，但行为完全不同：
- 团队协作中用
git merge：保留原始提交时间线和分支结构，git log --graph能清晰看到谁在哪天合了什么分支 - 个人分支整理历史用
git rebase：把你的多次提交“重放”到最新main顶端，得到线性历史；但一旦推送过该分支，rebase后必须git push -f，而-f在共享分支上是禁止操作 - GitHub/GitLab 上多数项目启用了分支保护，你根本不能
git push origin main，只能git push origin feature/login，然后点「New Pull Request」走审核流程
如果你不确定，就用 merge。它不改变任何已有提交，出错也容易回退。
推送失败？大概率是凭据或权限问题
执行 git push origin main 报 remote: Permission to xxx denied 或卡在用户名密码，不是网络问题，而是认证失效：
- Windows 用户：运行
control keymgr.dll打开「凭据管理器」→「Windows 凭据」→ 删除所有含git:、github.com、gitee.com的条目 - macOS 用户：打开「钥匙串访问」→ 搜索
github或git→ 删除相关 internet password 条目 - 之后首次
git push会弹新登录窗口，用 Personal Access Token（PAT）代替密码（尤其 GitHub 已禁用账号密码直连）
真正容易被忽略的点是：主分支是否受保护？很多团队要求 PR + Code Review + CI 通过才允许合并。这时候你本地 git merge 成功毫无意义，必须推自己的分支，等别人点 Merge 按钮。
