必须先签出目标分支再合并，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 更改」窗口，填写提交消息并点击「提交」按钮。
- 没提交前，分支指针仍停在合并前的位置，远程推送时也不会包含这次合并
- 如果中途关闭 VS 或崩溃，未提交的合并状态可能残留，下次打开会看到「未完成的合并」提示
- 提交消息建议写清楚来源，比如「Merge branch 'feature/search-api' into main」，方便追溯
遇到冲突别急着点「接受传入更改」
VS 内置的冲突编辑器会高亮冲突块，但默认选项容易误导人。「接受传入更改」= 放弃当前分支修改，全用源分支内容——这在多数功能合并场景下是错的。
- 仔细比对左右两栏：左边是当前分支（target）内容，右边是被合并分支（source）内容
- 真正要保留的是你当前分支的逻辑主干，只把 source 分支里需要的功能片段手工抄过去
- 改完后必须逐个文件点击「标记为已解决」，否则无法提交；漏掉一个，提交按钮仍为灰色
推送前务必检查「同步」按钮旁的数字提示
「Git 更改」窗口右上角的分支下拉框旁有个小数字，它同时显示两个信息：↑2 表示有 2 个本地提交未推，↓3 表示有 3 个远程提交未拉。合并后这个数字很可能变成 ↓1 或更高——说明别人在你合并期间又往 main 推了新提交。
- 此时直接点「同步」会失败，VS 会弹窗提醒「你的本地分支落后于远程」
- 正确做法：先点「拉取」→ 解决可能出现的新冲突 → 再提交 → 最后「推送」
- 跳过这步，强行用命令行
git push --force会覆盖他人提交，属于高危操作
