文本文件里出现是指在文本文件中出现了特定内容、字符、符号或异常现象，如乱码、空行、特殊控制字符、编码错误等，需结合具体上下文判断原因并处理。
文本文件里出现
这是 Git 插入的标准冲突标记，表示当前分支（HEAD）和待合并分支的修改发生了重叠。它不是 bug，也不是乱码，而是 Git 明确告诉你：“这里我没法自动决定留哪边，你来定”。标记结构固定为三段：（你的改动）、<code>=======（分隔线）、>>>>>> commit-hash（对方的改动）。中间任意一段都可能为空，比如对方删了整段而你改了，就会只看到你的内容和空的远程段。
手动编辑冲突文件的关键操作步骤
打开冲突文件后，不能只删标记就完事——必须保留逻辑正确的代码，并确保语法完整。常见疏漏包括：
- 只删了
和<code>>>>>>> commit-hash，却忘了删=======，导致残留无效符号 - 保留了两边都改过的函数定义，造成重复声明（如两个
function foo() { ... }） - 删掉某段时误删了紧邻的注释或空行，破坏缩进或可读性
- 没检查 JSON、YAML 等格式文件的括号/缩进是否匹配，导致后续解析失败
改完后务必用 git status 确认该文件状态从 Unmerged 变为 modified 或 to be committed，再执行 git add <file></file>。
为什么git add是必须的，不能直接git commit
git commit 默认只提交已暂存（staged）的变更。冲突文件在解决后仍处于“未暂存”状态，即使你已经保存并删掉了所有标记。Git 不会自动把编辑后的文件加进暂存区——这是防止误提交的保护机制。跳过 git add 直接 git commit 会导致：要么提交失败（提示“no changes added to commit”），要么只提交了其他已暂存文件，遗漏刚解决的冲突文件。实际中常有人卡在这一步，反复 git commit 却发现冲突还在。
遇到二进制文件冲突怎么办
图片、PDF、.docx 等二进制文件不会出现文本标记，git status 会显示类似 both modified: image.png。Git 无法逐行比对，所以只能选边站队：
- 保留自己版本：
git checkout --ours image.png - 保留对方版本：
git checkout --theirs image.png - 手动替换文件后，仍需
git add image.png标记为已解决
注意：--ours/--theirs 在 git merge 场景下含义明确；但在 git rebase 中语义反转，容易混淆——此时建议直接拷贝文件，避免依赖参数。
git add，或者在二进制文件上误用文本思维去“编辑”。只要盯住 git status 的输出，它永远会告诉你下一步该做什么。 
