必须先签出目标分支再合并，VS的“合并到当前分支”以当前分支为接收方；合并后需手动提交，否则无效；冲突时勿盲目选“接受传入更改”，应比对左右内容并标记已解决；推送前须拉取同步远程新提交。

你不需要先切到目标分支再手动执行 git merge；Visual Studio 的图形化合并操作本质是帮你封装了命令，但关键逻辑和顺序不能错——否则会合反方向、丢提交，甚至触发本可避免的冲突。

合并前必须确认当前签出的是目标分支

很多人误以为“右键选源分支 → 点合并”就完事，结果发现代码没进主干。根本原因是：VS 的「合并到当前分支」动作，永远以你当前所在的分支为 接收方（即目标分支），而不是右键的那个分支。

• 要把 feature/login 合入 main，你得先签出 main（双击它或右键 → Checkout）
• 再右键 feature/login → 选择「将 feature/login 合并到当前分支」
• 如果当前在 feature/login 上，却对 main 右键选合并，实际执行的是 git merge main —— 即把 main 合进 feature，不是你要的结果

合并后不提交 = 白忙一场

VS 执行完合并，只是把变更加载进工作区和暂存区，不会自动生成合并提交。你必须主动进入「Git 更改」窗口，填写提交消息并点击「提交」按钮。

Git Changelog Generator

使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……

下载

• 没提交前，分支指针仍停在合并前的位置，远程推送时也不会包含这次合并
• 如果中途关闭 VS 或崩溃，未提交的合并状态可能残留，下次打开会看到「未完成的合并」提示
• 提交消息建议写清楚来源，比如「Merge branch 'feature/search-api' into main」，方便追溯

遇到冲突别急着点「接受传入更改」

VS 内置的冲突编辑器会高亮冲突块，但默认选项容易误导人。「接受传入更改」= 放弃当前分支修改，全用源分支内容——这在多数功能合并场景下是错的。

• 仔细比对左右两栏：左边是当前分支（target）内容，右边是被合并分支（source）内容
• 真正要保留的是你当前分支的逻辑主干，只把 source 分支里需要的功能片段手工抄过去
• 改完后必须逐个文件点击「标记为已解决」，否则无法提交；漏掉一个，提交按钮仍为灰色

推送前务必检查「同步」按钮旁的数字提示

「Git 更改」窗口右上角的分支下拉框旁有个小数字，它同时显示两个信息：↑2 表示有 2 个本地提交未推，↓3 表示有 3 个远程提交未拉。合并后这个数字很可能变成 ↓1 或更高——说明别人在你合并期间又往 main 推了新提交。

• 此时直接点「同步」会失败，VS 会弹窗提醒「你的本地分支落后于远程」
• 正确做法：先点「拉取」→ 解决可能出现的新冲突 → 再提交 → 最后「推送」
• 跳过这步，强行用命令行 git push --force 会覆盖他人提交，属于高危操作

合并操作本身几秒就完，真正耗时和易出错的环节都在前后：签出是否准确、提交是否执行、冲突是否审慎处理、远程状态是否同步。这些步骤没有魔法，但每一步都卡在 Git 的底层语义上——VS 只是界面，不是解释器。