Git怎么查看文件修改差异_Git diff对比文件变更详解【技巧】
Git diff 对比文件变更详解：从“看不到修改”到精准解读 git diff 看不到修改？检查工作区和暂存区状态 很多开发者第一次遇到 git diff 没反应时都会愣一下：明明改了文件，怎么什么都没显示？其实，这恰恰是理解 Git 设计逻辑的关键一步。 默认情况下，git diff 这个命令只
Git diff 对比文件变更详解：从“看不到修改”到精准解读
git diff 看不到修改？检查工作区和暂存区状态
很多开发者第一次遇到 git diff 没反应时都会愣一下：明明改了文件，怎么什么都没显示？其实，这恰恰是理解 Git 设计逻辑的关键一步。
默认情况下，git diff 这个命令只做一件事：对比工作区（就是你正在编辑的文件）和暂存区（执行过 git add 后的状态）。一旦你把修改添加到了暂存区，对于默认的 git diff 来说，这次修改就“消失”了。所以，排查问题的第一步，就是搞清楚你的修改到底处在哪个阶段。
- 想查看那些还没执行
git add的修改？直接运行git diff就行。 - 修改已经暂存了，想看看暂存区和上一次提交有什么不同？这时候得用
git diff --cached（--staged是它的别名，意思一样）。 - 想一口气看到工作区和暂存区里所有相对于最新提交的改动？
git diff HEAD命令可以满足你。 - 养成个好习惯：在执行
git status之前，先用上面这几条命令快速扫描一下，你就能对当前所有变更的“分布图层”一目了然。
对比两个分支或提交时，注意方向和含义
当需要比较分支间的差异时，git diff A..B 和 git diff A...B 这两个写法只差一个点，但含义天差地别，用错了很容易得到一堆无关信息。
A..B 表示的是“提交 B 相对于提交 A 的所有变更”。而 A...B 就微妙了，它指的是“提交 B 相对于 A 和 B 的共同祖先的变更”，换句话说，就是 B 分支上独有的那些改动。这个区别在合并或变基后尤其重要。
- 典型场景：你想检查 feature 分支比 main 分支多改了哪些东西。正确的姿势是：
git diff main...feature。 - 如果误用了
main..feature，输出里可能会包含大量来自合并历史的、并非 feature 分支独有的修改，特别是在进行过 rebase 操作后，输出会显得非常混乱。 - 对比内容太多刷屏？可以加上文件路径来聚焦，比如
git diff main...feature -- src/utils.js。 - 在全面对比前，先用
--stat选项看看改动分布是个好主意：git diff --stat main...feature，它能简洁地列出改了哪些文件，以及增删的行数概况。
diff 输出里“a/”“b/”前缀和模式变化是什么意思
初看 git diffdiff --git a/src/index.js b/src/index.js。这里的 a/ 和 b/ 别紧张，它们不是真实的目录，只是 Git 内部用来标记“变更前版本”和“变更后版本”的符号。真正需要关注的是后面跟着的实际文件路径。
有时候，git diff 会输出一些看似奇怪的变化：
- 如果看到
old mode 100644 / new mode 100755这样的行，别急着看内容——这仅仅表示文件的权限模式变了（例如从普通文件变成了可执行文件），文件内容本身可能毫无改动。 - 遇到提示
Binary files a/image.png and b/image.png differ，意思是 Git 检测到这是二进制文件（如图片），并且它们不同。Git 默认不会展示二进制文件的具体差异。除非你明确知道在做什么，否则不要用--text选项去强制当文本比较，对于二进制文件，专门的工具（如xxd）更合适。 - 差异内容部分，行首的
-表示删除，+表示新增。但要注意，Git 很智能，对于重命名或移动文件，它会进行“相似度检测”。如果看到similarity index 95%这样的提示，那说明 Git 认为这是一个文件被移动或重命名了，而不是简单的删除旧文件、新增新文件。
中文文件名乱码或 diff 不生效？查 core.quotePath 和系统编码
在 Windows 或某些 Linux 终端环境下，git diff 输出的中文文件名可能变成像 "\344\270\255\346\226\207.js" 这样的八进制转义序列。这其实不是乱码，而是 Git 的一种保护机制（core.quotePath），它默认会对非 ASCII 字符的路径进行转义。
- 临时解决方案：如果确认你的终端支持 UTF-8 编码，可以关闭这个转义：
git config --global core.quotePath false。 - 更根本的调整：让 Git 更好地识别系统编码。例如，在 Windows 上，可以尝试设置：
git config --global core.precomposeUnicode true。 - 如果
git diff完全“无视”某个中文文件的变更，先别怪编码。检查一下这个文件是否被.gitignore规则忽略了，或者是否曾经被标记为assume-unchanged（通过git update-index --assume-unchanged命令）。 - Mac 用户有个特殊点：默认的 HFS+ 或 APFS 文件系统是大小写不敏感的，但 Git 默认是大小写敏感的。这可能导致你重命名文件时（仅改变大小写），
git diff无法正确识别出这是一个重命名操作。
说到底，git diff 的复杂性不在于命令本身有多少参数，而在于你能否清晰地告诉 Git 三个问题：“拿什么和什么比？”（工作区、暂存区、提交？）、“比的是什么？”（全部内容、特定路径？）、“路径和编码怎么算？”。把这三个维度理清楚，参数自然就用得对了。
遇到Git合并冲突别慌张，本文详解冲突产生的原因及标准处理流程，涵盖查看冲突文件、理解标记含义、手动修改代码及完成合并提交的完整步骤，助你高效解决协作开发中的代码冲突问题。
想知道如何用Git创建名为bip的分支？本文提供清晰的命令行操作步骤，包括本地创建、切换分支以及推送到远程仓库的方法，适合初学者快速上手。
本文指导GitLab新手完成创建项目并推送第一次提交的最小闭环。涵盖远程项目创建、本地仓库初始化、添加远程地址及执行git push。重点说明HTTPS与SSH认证差异、分支名（master/main）核对及提交验证标准，确保远程仓库真正建立。
Chrome官方免验证入口为https://www.google.cn/chrome/，提供全平台安装包、免登录即用、本地化安全机制及引擎级性能优化。 到底该去哪里找正版、免费且无需繁琐验证的Chrome浏览器入口？这个问题困扰了不少网友。今天，我们就来直通核心，为大家详细拆解Chrome引擎的官方
命令式编程关注执行步骤，声明式描述目标，函数式强调无副作用。回调函数作为参数传递，可导致回调地狱，后由Promise解决。仿函数重载`operator()`，lambda更轻量。元编程生成代码，如模板、装饰器、宏，提升抽象能力。
Python项目配置.gitignore应排除__pycache__、虚拟环境（venv/.venv等）、IDE生成文件（.idea/.vscode等）及缓存目录。误提交后需用`gitrm--cached`移除索引。建议复用GitHub官方模板并验证规则有效性。
VSCode不保存历史冲突记录，仅在合并时实时标记冲突文件。冲突文件位于源代码管理面板的MERGECHANGES分组，带红色感叹号和冲突数量。点击文件以三栏合并编辑器显示当前分支、传入分支和结果区，供用户编辑解决冲突。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力，依托字节自研豆包多模态大模型，凭借火山方舟一站式平台，提供模型精调、推理部署、智能应用搭建等全链路服务，结合高性能AI算力，助力各行业快速落地大模型数字化与智能化应用。
