vs2022企业协作必须守住三道git红线：分支隔离、提交前必拉取、推送前本地验证；跳过任一环节易致同步失败。强制先pull后push，配置rebase避免污染历史；commit需语义化前缀并严格校验暂存区；分支命名须规范，删除前确认已合并；冲突必须在vs内解决。
VS2022 企业级团队协作中，Git 不是“能用就行”，而是必须守住三道线：分支隔离不越界、提交前必拉取、远程推送前本地已验证。跳过任一环节，三天后你大概率会在“同步失败”弹窗里反复点击重试。
先 git pull 再 git push：不是建议，是强制流程
多人高频修改同一模块时，git push 直接失败或触发非快进（non-fast-forward）拒绝是常态。VS2022 的“同步”页点一次 Pull 并不等于安全——它只拉取当前分支，不自动合并其他活跃分支的变更。
- 正确操作：在“团队资源管理器”→“同步”页，先点
Pull，再手动点Merge（如果远程有新分支或你本地有未跟踪分支） - 容易踩的坑：
Pull后没检查“未提交更改”面板，误以为已同步；实际可能有未拉取的远程 tag 或 submodule 更新 - 企业场景下建议：把
git config --global pull.rebase true加入全局配置，避免无意义的 merge commit 污染主干历史
git commit 必须带语义化前缀，且不能绕过 VS 的暂存区校验
VS2022 默认启用“暂存文件”机制，但开发人员常直接右键“提交更改”，跳过逐个确认改动内容。这会导致二进制文件、临时生成文件（如 .user、.suo）被意外提交，后续 CI 构建失败。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 必须做：
git commit -m "feat(api): add user role validation"这类格式，企业 CI 流水线通常依赖前缀触发不同构建策略 - VS 中关键动作：提交前务必展开“更改”列表，勾选真正要提交的文件；禁用“自动暂存更改”选项（设置 → 源代码管理 → Git → 取消勾选）
- 注意：
.gitignore在 VS 中不实时生效——若文件已被追踪，改 ignore 无效，需先执行git rm --cached <file></file>
分支命名与生命周期管理：别让 git branch -d 成为定时炸弹
企业项目中，feature/xxx、hotfix/yyy 等前缀不是风格问题，而是权限控制和自动化发布的依据。VS2022 的图形界面隐藏了 -d 和 -D 的区别，误点“删除分支”可能删掉未合入的修改。
- 安全删除前提：分支必须已完整合并到目标基线（如
develop），且远程对应分支已删除（git push origin --delete feature/abc） - VS2022 中识别风险：右键分支名 → “查看提交” → 检查顶部是否显示“已合并到 develop”；若显示“未合并”，禁止删除
- 推荐做法：企业统一使用
git branch --merged develop | grep -v "develop\|main" | xargs git branch -d批量清理，而非依赖 UI 点击
冲突解决必须在 VS 内完成，禁止切终端手动编辑 .orig 文件
VS2022 的“合并冲突”工具会高亮冲突块、提供“接受传入更改/当前更改/两者”三向选择，并自动更新 .csproj 等结构化文件的 XML 节点顺序。一旦切到命令行手动改 .cs 文件里的
- 实操要点：冲突发生后，立刻在“团队资源管理器”→“更改”页点击“合并冲突”，不要关闭当前解决方案
- 特别注意：.csproj 文件冲突必须用 VS 内置编辑器处理，手动合并易导致 NuGet 包引用丢失或编译报错 CS0006
- 隐藏陷阱：VS2022 默认不显示“未跟踪的冲突文件”，需在“更改”面板顶部切换“显示未跟踪的文件”开关才能看到全部待处理项
企业环境里最常被忽略的其实是 Git 配置的继承关系：VS2022 读取的是系统级 ~/.gitconfig，而不是项目根目录下的 .git/config。一个团队成员本地设置了 core.autocrlf=true，另一个设为 input，就会在换行符上持续产生脏提交——这种问题不会报错，但会让每次 git diff 都飘着一堆无关的 ^M。
