Git 冲突和线上发布异常怎么处理
先理解原理和示例，再练习完整口述与追问。
回答要点
讲清 merge / rebase 的影响，先确认分支状态再解决冲突；了解中止操作。发布重点准备资源 hash、入口缓存、CDN、旧页面引用旧 chunk、灰度与回滚，不把“重新发布”当作全部方案。
原理拆解
冲突解决是合并业务语义，不是把标记删除。先理解双方修改原因和调用契约，选择保留、组合或重新实现，再运行受影响验证。发布异常则先稳定用户体验，确认是否要回滚，再按版本、资源、配置和接口兼容定位。可追溯的构建与发布记录比手改线上文件更可靠。
示例与推演
两个分支分别给查询增加权限过滤和分页修复，冲突时不能随意只选 ours/theirs。保留权限与页码规则后验证查询、删除与异常。线上若旧 HTML 引用已删除 chunk，回滚页面或恢复资源，并修复先资源后 HTML、保留旧版本的发布顺序。
易错点
不擅自强推覆盖共享历史。回滚前确认数据库和接口是否已发生不兼容变化；前端回退不一定能撤销后端变更。
参考回答可直接练习口述
多人协作先确认分支和未提交改动，merge 保留合并关系，rebase 把提交重放到新基点；冲突要理解双方业务后解决。正在 merge 可用 git merge --abort，中止 rebase 用 git rebase --abort，不能随意重写已共享历史。线上发布异常先止损并对比版本，检查 HTML 入口、内容 hash 资源、CDN 与旧 chunk 保留。回滚要确保入口和资源可共同恢复，而不是只替换一半文件。