Git合并冲突时部分修改“消失”是因为误用git checkout --ours/--theirs强制覆盖整个文件，而非手动编辑保留所需内容；正确流程是删除冲突标记、选择性保留修改、git add标记已解决、再git commit。
冲突发生后，代码不会自动丢，但“保留”不是默认动作——它取决于你用什么命令、在什么状态、是否处理了未跟踪文件。
git merge 冲突时，为什么部分修改“消失”了
执行 git merge 出现冲突后，Git 会把双方修改都保留在工作区，但只把无冲突部分放进暂存区；有冲突的文件会处于 Unmerged 状态，git status 显示为红色。此时如果直接 git checkout --ours 或 git checkout --theirs，会强制覆盖整个文件内容，导致另一方的改动被清空。
- 误操作常见于：看到冲突提示后没细看文件列表，直接对所有冲突文件批量执行
git checkout --ours -
--ours指的是当前分支（MERGE_HEAD 之前）的版本，--theirs指的是被合并分支的版本——注意：rebase 场景下含义相反 - 真正安全的做法是先打开冲突文件，手动保留需要的部分，再
git add标记为已解决
stash pop 后冲突，代码“回不去了”的真实原因
很多人在 git stash pop 后发现代码不对，不是 stash 丢了，而是应用到了错误的 HEAD 上。典型场景是：你在 main 分支上 stash，然后 git checkout feat-x，再 git stash pop —— 这时 stash 是应用到 feat-x 分支上的，如果该分支和 main 的文件差异大，就容易触发冲突，且恢复路径变复杂。
系统化设计数字化解决方案，涵盖方案类型识别、政策背景分析、需求分析、建设思路设计、架构设计（业务、功能、数据、技术四维度）、技术选型、具体建设内容、实施规划、风险评估和投资估算的全流程能力。适用于规划类、申报类、可研类、投标类和工作汇报类等多种方案产出场景，覆盖政府数字化转型和企业数字化转型两大核心领域。
- stash 默认不保存未跟踪文件（
?? file.txt），pop 后这些文件还在原地，可能和新应用的修改重名、覆盖或引发逻辑错误 - 如果 pop 后出现冲突，
git stash drop不会执行，stash 记录仍在；但若你手快git stash pop失败又补了git stash drop，那条 stash 就真没了 - 恢复方式：用
git stash apply stash@{0}（不删除）反复试，配合git diff确认内容是否完整
未跟踪文件（untracked files）是最大盲区
Git 对未跟踪文件几乎“视而不见”：stash 不收、checkout 不动、merge 不管。它们始终躺在工作区，却可能在你切分支、pop stash、merge 后悄悄混入新上下文，造成行为异常或编译失败。
- 判断是否存在未跟踪文件：
git status --porcelain | grep "^??" - 想一并管理？stash 时必须加
-u：git stash push -u -m "wip" - 不想进版本库但又怕丢失？临时
git add -N path/to/file（告知 Git “我知道它存在”，但不加入内容） - 真要清理？
git clean -n先预览，确认无误再git clean -fd
最常被忽略的点：冲突解决不是“删掉标记就完事”，而是“删标记 + git add + git commit”三步闭环；少任何一步，Git 都认为冲突还存在。尤其在 IDE 里点“解决冲突”后，别忘了手动 git add，否则 git status 仍显示红色，git commit 会报错。
