Git解决冲突后需手动git add标记已处理，否则commit报错；合并提交信息须保留默认格式；推送前应设置上游分支；合并后需验证功能并核对删除的代码。
冲突标记清除后必须手动 git add
Git 解决冲突不是自动完成的，它只负责停在冲突点并高亮差异。你手动编辑完文件、删掉 、=======、>>>>>> feature/login 这些标记线后，文件仍处于“未暂存”状态。此时 git status 会显示该文件在 “Unmerged paths” 下，且状态为 both modified。
必须显式执行：
git add <conflicted-file></conflicted-file>
否则后续 git commit 会报错：fatal: cannot do a partial commit during a merge。这不是 Git 故意卡你，而是它强制要求所有冲突文件都通过 add 明确声明“已处理完毕”。
- 一次解决多个文件？挨个
git add，或用git add .（但注意别误加不该提交的临时文件） - 只想加当前目录下所有已解决的冲突文件？
git add --update或git add -u - 加完后
git status应显示该文件进入 “Changes to be committed”，不再出现在 Unmerged 区域
git commit 时不要改默认提交信息
Git 在检测到合并冲突后执行 git commit，会自动弹出编辑器，预填充一条形如 Merge branch 'feature/login' into main 的提交信息。这是 Git 合并流程的标识，也是后续排查历史的关键线索。
直接保存退出即可，不要删掉、不要重写、不要改成 fix bug 这类模糊描述。否则：
- CI/CD 流水线可能依赖该格式识别合并行为
- 团队协作中他人无法快速区分普通提交和合并提交
- 用
git log --merges查合并记录时会漏掉这条
如果真想补充说明，可以在默认信息下方空一行，追加自己的备注，例如：
Merge branch 'feature/login' into main
- 修复登录页 token 刷新逻辑
- 保留旧版 session fallback 路径
推送前确认当前分支和远程跟踪关系
很多人解决完冲突就顺手 git push，结果报错：fatal: The current branch main has no upstream branch.。这说明本地分支还没和远程分支建立跟踪关系。
检查方法：
git branch -vv
输出中如果当前分支后面没显示 [origin/main] 这类字样，就得先设置上游：
- 首次推送该分支：用
git push --set-upstream origin main - 已存在远程分支但没关联：用
git branch --set-upstream-to=origin/main main - 不确定远程分支名？先
git fetch拉取最新引用，再git ls-remote --heads origin看实际存在的分支名
推送命令本身不能省略分支名——git push origin main 比 git push 更明确、更安全。
合并后别急着删分支，先验证再操作
冲突解决 + 提交 + 推送成功，不代表功能就稳了。常见疏漏：
- 只测试了冲突文件，没跑完整流程（比如登录分支合入后，没测登出、token 过期等边界）
- 本地
main已更新，但 CI 流水线拉的是旧缓存，导致构建失败 - 远程分支被其他人同时推送过新提交，你的合并提交其实只是“局部最新”
建议动作：
- 本地
git pull --rebase再拉一次，确认无新提交；有则说明别人已推进，你得重新测试 - 在 CI 通过、QA 确认功能正常后，再执行
git branch -d feature/login - 远程分支删除是独立操作：
git push origin --delete feature/login，别指望本地删了远程也跟着消失
最常被忽略的一点：解决冲突时手动删掉的代码行，可能本该保留——尤其当冲突块里混着多人修改，而你只盯着“自己写的那部分”删掉了“别人刚加的兼容逻辑”。所以冲突文件一定得对照 PR/Commit diff 再扫一眼。
