推荐使用 git switch，它语义更清晰、安全性更高：git switch develop 切分支，git switch -c new-branch 创建并切换；而 git checkout 一身多职，易混淆且风险高，Git 2.23+ 已将其分支功能拆分为 git switch 和文件恢复功能的 git restore。
git switch 和 git checkout 切分支的区别
现在推荐用 git switch，它比 git checkout 语义更清晰、出错率更低。比如你想切到 develop 分支，直接运行：
git switch develop
如果目标分支还不存在，git switch -c new-branch 会新建并切换；而 git checkout -b new-branch 虽然也能做到，但 checkout 还要负责“恢复文件”这种完全不同的事，容易混淆。老项目里看到 git checkout 不用慌，但它在新 Git（2.23+）中已被拆分为 switch 和 restore 两个专用命令。
合并远程最新代码的三种常见场景
切换过去只是第一步，真正要“合并最新代码”，得看你是想同步远端主干、集成他人改动，还是拉通自己功能分支。关键不是“怎么合”，而是“从哪合、合到哪”：
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
- 想让本地
develop跟上远端origin/develop？先git switch develop，再git pull origin develop—— 这本质是fetch + merge，Git 默认会 fast-forward 合并（没冲突就直接移动指针） - 你正在
feature/login上开发，需要把develop的最新修复带进来？先git switch feature/login，再git merge develop。注意：别在develop上执行git merge feature/login，顺序反了会导致历史混乱 - 团队要求提交历史线性整洁（比如 GitLab MR 要求），那就不能直接 merge，得用
git rebase develop（前提是feature/login还没推送到远端）。但一旦已push，就绝对不要rebase，否则会强制覆盖远端历史，别人pull时会出 38 个冲突文件那种灾难
git pull 失败常见报错和应对
最常卡在 “Your local changes to the following files would be overwritten by merge” 或 “refusing to merge unrelated histories”。前者说明你工作区有未提交改动，Git 拒绝覆盖；后者多见于 clone 了一个全新仓库又想合并另一个已有历史的分支。
- 遇到覆盖警告：先
git status看哪些文件被改了，要么git add && git commit提交，要么git stash暂存，等pull完再git stash pop - 遇到 unrelated histories：确认是否真要合并两个无关仓库（比如把旧项目代码合进新脚手架），如果是，加
--allow-unrelated-histories参数，但务必提前备份——这个操作不可逆 - 如果
pull自动触发了合并提交（出现 vim 编辑器让你输 message），说明发生了真正的三方合并（不是 fast-forward），这时别乱关终端，输完描述保存退出即可；想跳过这步，下次用git pull --ff-only，失败就立刻报错，逼你手动处理
为什么 git merge develop 后看不到新代码？
这通常不是 Git 的问题，而是你没意识到：merge 只更新了 Git 的提交指针和索引，工作区文件是否刷新，取决于有没有冲突。如果 merge 是 fast-forward，文件自动更新；如果有冲突，Git 会停在中间状态，git status 显示 unmerged paths，对应文件里会塞满 <<<< 和 >>>> 标记——你得手动编辑、删标记、git add、再 git commit 才算完成。很多人卡在这一步，以为“已经 merge 了”，其实连冲突都没解决。
复杂点在于：merge 冲突可能藏在看似无关的文件里，比如两个人同时改了同一行的注释格式，或一个删了空行、一个加了日志，Git 会当成冲突。所以别只盯着报错文件，git status 输出的所有 modified/unmerged 文件都得过一遍。
