Git提交前须检查工作区、暂存区、本地仓库状态；VSCode Git图标数字≠已提交数；commit message需首行≤50字符且空行分隔；合并前须fetch并确认HEAD指向；冲突解决后保存即自动git add，不可逆。
Git 提交前必须检查的三个状态
没提交成功，往往不是命令写错，而是工作区、暂存区、本地仓库三者状态混乱。用 git status 看到 “nothing to commit” 却仍推不上去？大概率是文件根本没进暂存区。
- 用
git add -A比git add .更稳妥——它会同时跟踪新增、修改、删除的文件，而.会忽略已删除文件 - 如果改了文件但
git status显示 “modified”，说明还没git add；如果显示 “staged for commit”，才真正进了暂存区 - VSCode 左下角 Git 图标数字 ≠ 已提交数，它只统计“已暂存 + 未暂存”的变更总数，别被误导
VSCode 内提交时 commit message 的实际约束
VSCode 自带的提交框看似自由，但 Git 服务端（比如 GitHub、GitLab）常强制要求首行不超过 50 字符、正文缩进、空行分隔。直接敲长段落，后续 git push 可能被 hook 拦截。
- 在 VSCode 提交面板里，第一行自动作为 subject，回车后第二行起才是 body；想加 body 必须手动空一行，否则全被当 subject 处理
- 如果用
git commit -m "xxx"命令补提交，-m只取第一个引号内内容，多条-m才能模拟 body，但 VSCode GUI 不支持这种写法 - 建议在 VSCode 设置里开启
"git.alwaysSignOff": true，避免协作时因缺Signed-off-by被 CI 拒绝
合并分支前必须确认的两个 HEAD 指向
git merge feature/login 看似简单，但出问题基本都卡在当前所在分支和目标分支的 HEAD 是否干净、是否最新。VSCode 右下角显示的分支名只是“当前检出分支”，不代表它已同步远程最新提交。
- 执行合并前，先运行
git fetch（VSCode 点右上角同步按钮也等价于此），再用git log --oneline --graph origin/main main对比本地与远程main差异 - 如果当前在
main分支，想合入feature/login，确保feature/login已git rebase main过（或至少git merge main过），否则可能引入重复提交或冲突加倍 - VSCode 合并弹窗里选错目标分支很常见：它默认把“当前分支”当 base，“点击的分支”当 head，和 CLI 的
git merge <branch>语义一致，但 UI 上不强调这点，容易点反
解决合并冲突时 VSCode 内置编辑器的真实行为
VSCode 的冲突编辑界面（有 >>>>>> 标记）不是只读预览，它是可编辑的实时工作区。保存后 VSCode 会自动执行 git add 标记为已解决——但这一步不可逆，且不校验语法或逻辑正确性。
- 不要直接删掉所有冲突标记然后乱填代码；应保留一方逻辑，再手动整合另一方改动，最后删标记。VSCode 不会帮你判断哪边该留
- 如果改完保存后发现不对，别急着
git checkout --ours；先用git restore --staged <file>把暂存区撤回，再git checkout --conflict=merge <file>重载冲突视图 - 对
.json或配置类文件，VSCode 的合并控件（Accept Current Change / Accept Incoming Change）经常误判结构层级，建议切到纯文本模式手动处理
git fetch 和 git rebase 这两步——它们不显眼，却决定合并是不是真的一键完成。 
