“同步”按钮不能代替“先拉取再推送”，因其默认执行 git pull --rebase，遇冲突会中断且易打乱提交顺序；应先拉取确认“传入”为0再推送。
Visual Studio 2022 中 Git 集成足够好用，但直接点按钮不等于真会用——很多团队问题其实源于对“拉取/推送时机”“分支生命周期”和“暂存区语义”的误解。
为什么“同步”按钮不能代替“先拉取再推送”
VS 的 同步 按钮看似一步到位，实则隐含风险：它会在后台自动执行 git pull --rebase（取决于设置），若本地有未推送的提交且远程已有新提交，rebase 过程中一旦出错，可能丢失提交哈希或打乱逻辑顺序。
- 真实场景：你本地提交了
feat: add logging，同事刚推了fix: null ref in auth，此时点同步，VS 默认尝试 rebase —— 若你的提交修改了同一段代码，rebase 会中断并要求你手动解决冲突，而此时你甚至没看到原始pull的结果 - 更稳妥做法：始终先点
拉取，观察“传入提交”数量；确认无冲突或已解决后，再点推送 - 关键检查点：在
Git 更改窗口顶部，留意“传出”和“传入”的数字。只有当“传入”为 0 时，才适合直接推送
“暂存更改”不是“保存文件”，而是 git add 的精确映射
新手常误以为点了文件名旁的 + 就是“保存了修改”，其实这只是把工作区改动加入暂存区（index），和 git add 完全等价。未暂存的文件不会出现在后续提交中。
- 典型错误：改了
Program.cs和appsettings.json，只给前者点+，提交后发现配置变更没带上 - VS 中的“全部暂存”按钮对应
git add .，但会跳过.gitignore规则；而右键单个文件选“暂存”才是精准控制 - 注意：VS 的“暂存”操作不支持部分暂存（partial staging），如只想提交某次修改中的几行——这种情况必须切到终端用
git add -p
创建分支后必须手动推送，否则远程不可见
VS 创建分支（如通过顶部分支下拉菜单 → “新建分支”）只是本地行为，git branch 命令执行完毕，远程仓库里压根没有这个分支的影子。
- 常见困惑：“我在 VS 里建了
feature/login，为什么 GitHub 上看不到？”——因为没推送 - 正确路径：建完分支 → 切换到该分支 → 在
Git 存储库视图中右键该分支 → 选推送分支；或打开终端执行git push --set-upstream origin feature/login - 省事技巧：勾选 VS 设置中的“推送新分支时自动设置上游”，之后首次推送就不用再输
--set-upstream
合并冲突时，VS 的图形化工具比命令行更易误操作
VS 内置的“合并冲突”视图会高亮冲突块，并提供“接受传入”“接受当前”“接受两者”三个按钮，但这些操作是**直接写入文件并自动标记为已解决**，没有二次确认。
- 危险操作：在冲突文件中点了“接受传入”，结果覆盖了自己刚写的业务逻辑，而你根本没注意到下方还有另一处冲突块
- 建议流程：先在
Git 更改窗口点开冲突文件 → 拉到底部看完整冲突标记（到 <code>>>>>>> other-branch）→ 手动编辑，删掉标记行，保留合理逻辑 → 再点“标记为已解决” - 底线提醒：任何合并操作前，确保已提交或存储（
git stash）当前未完成的工作，否则冲突解决失败会导致工作区混乱
Git 在 VS 里藏得最深的坑，往往不是功能缺失，而是界面把底层语义简化过了头——比如“暂存”听起来像保存，“同步”听起来像一键更新。实际使用时，得时刻心里默念它背后对应的那条命令，才能避开静默丢数据的陷阱。
