vscode的pull按钮默认执行git pull origin ，等价于git fetch + git merge；同步更改按钮则按顺序执行git pull --rebase + git push。
VSCode 默认用 git merge，不是变基；想用 rebase 必须手动触发或改设置，否则点“Pull”永远走合并流程。
VSCode 的 Pull 按钮默认执行什么命令
点击源代码管理视图右上角的 同步更改（或按 Ctrl+Shift+P 运行 Git: Pull），VSCode 实际执行的是：
git pull origin <current-branch></current-branch>
而 Git 默认配置下，git pull 等价于 git fetch + git merge，不是 rebase。这意味着：
- 即使你本地有未推送的提交，Pull 也会产生一个「merge commit」，历史线分叉
- VSCode 不会自动把你的提交“挪到远程最新提交之后”，除非你明确要求
- 状态栏显示 “Merged branch 'main' into feature/login” 就是它走 merge 的铁证
怎么让 VSCode Pull 时自动变基而不是合并
必须改 Git 配置，VSCode 本身不提供 UI 开关。在终端运行：
git config --global pull.rebase true
或针对当前仓库：
git config pull.rebase true
生效后，VSCode 的 Pull 操作就变成 git fetch + git rebase。但要注意：
- 如果本地有未提交的改动，
rebase会失败并报错error: cannot rebase: You have unstaged changes—— 必须先git add或git stash - 变基过程中遇到冲突，VSCode 会打开合并编辑器，但解决后要运行
git rebase --continue（不能只点 Stage） - 一旦开始 rebase，就不能靠 VSCode 的“Commit”按钮完成，必须切终端输命令
Merge 和 Rebase 在 VSCode 里操作体验的关键差异
表面都是解决冲突，但底层逻辑和后续动作完全不同：
-
Merge 流程：冲突解决 →
git add→ VSCode 点 Commit 按钮 → 自动生成 merge commit → 可直接 push -
Rebase 流程：冲突解决 →
git add→ 必须在终端输git rebase --continue→ 若还有提交要重放，会再次停在下一个冲突 → 全部完成后才可 push - VSCode 的“同步更改”按钮在 rebase 过程中会变灰，无法点击，这是正常现象，不是卡死
- 误用
git merge --abort会中断 rebase，但 VSCode 不会自动恢复工作区，得手动git rebase --abort才能退出
什么时候该选 Merge，什么时候硬上 Rebase
别被“线性历史更干净”带偏。真实协作中：
- 团队共用分支（如
main、develop）上，永远用 merge —— 避免重写已推送的提交，防止别人git pull出乱子 - 自己本地的 feature 分支，在推送到远程前想整理提交记录（比如 squash 多个
fix typo），可用git rebase -i，但这和 VSCode 的 Pull 无关 - 如果你看到同事的提交 SHA 发生变化，大概率是他强制推送了 rebase 后的历史 —— 这是协作红线，VSCode 不会阻止，但你应该阻止
最易忽略的一点：VSCode 的“Git: Pull from Remote”命令不读取 pull.rebase 配置，它始终走 merge。真要变基，只能靠改全局配置 + 点顶部同步按钮，或者干脆别点，全用终端。
