企业官网建设流程全解析

1. 项目概述：为什么你每天都在用git diff，却从未真正“看见”它？

在 Git 的所有命令里，git diff是最沉默、最勤恳、也最容易被低估的那个。它不创建快照，不移动指针，不合并历史——它只做一件事：把变化摊开在你面前，一行一行，清清楚楚。这不是一个“功能”，而是一种代码呼吸的节奏感：你改了什么？改在哪？改得对不对？改得有没有副作用？这些疑问，全靠git diff给出第一手答案。

我带过十几支开发团队，从五人初创到百人产研，见过太多真实场景：

• 新人提交前没git diff --staged，结果把本地调试用的print("DEBUG")和临时注释一起推上主干；
• 同事合并 PR 前只扫一眼文件列表，没细看git diff main feature-x，导致两个分支对同一配置项做了冲突修改，上线后服务直接报错；
• 排查一个线上 bug，翻了三天 commit 记录，最后发现git log -p -S"cache_timeout"三秒就定位到问题引入点——那行被悄悄删掉的超时配置。

这些都不是“会不会用”的问题，而是有没有建立起对 diff 的肌肉记忆和直觉判断。git diff的本质，不是比对工具，而是代码演化的显微镜。它背后支撑的是 Git 最核心的“三树模型”（Working Directory / Staging Area / Repository），而绝大多数人只把它当成git status的补充说明。

这篇文章不讲概念复读，不列命令大全。我会带着你亲手搭建一个数据处理项目，从初始化那一刻起，每一步修改都用git diff实时追踪，拆解每一行输出的含义，解释为什么-U5比默认的-U3更适合审阅算法逻辑，为什么--color-words在重构函数签名时能救命，甚至告诉你什么时候该果断放弃终端里的黑白文本，直接git difftool呼出 VS Code 做侧边对比。

你不需要是 Git 内核开发者，但必须明白：每一次git commit的底气，都来自你对git diff输出的绝对信任。现在，我们从零开始，把这面镜子擦亮。

2. 核心设计思路：为什么git diff的三种基础对比模式，构成了所有复杂操作的基石？

2.1 三棵树不是比喻，而是 Git 运行时的真实内存结构

很多教程说“Working Directory、Staging Area、Repository 是三棵树”，听起来像抽象模型。但实际在 Git 执行git diff时，它确实在内存中加载了三个独立的文件快照副本进行逐字节比对。这不是设计哲学，而是工程实现——因为只有这样，才能保证git diff的输出完全可重现、零歧义。

举个具体例子：当你执行git diff（无参数）时，Git 并非简单地“读取当前文件内容”，而是：

1. 解析.git/index文件：这个二进制文件精确记录了 Staging Area 中每个文件的 SHA-1 哈希值、权限、时间戳；
2. 读取工作目录对应文件：计算其当前内容的 SHA-1；
3. 调用内部 diff 算法：将两个哈希值对应的 blob 对象（存储在.git/objects/下）加载进内存，逐行比对；
4. 生成统一格式输出：严格遵循diff -u标准，确保任何支持该格式的工具（如 IDE、CI 系统）都能解析。

提示：你可以用git ls-files --stage查看 Staging Area 当前所有文件的哈希值，用git hash-object <file>计算工作目录文件的哈希，亲自验证它们是否一致。这是理解 diff 基础的黄金实验。

2.2 三种基础对比模式的不可替代性

关键洞察：这三种模式不是“选项”，而是 Git 工作流中三个强制检查点。就像汽车的三重刹车系统——油门（修改）、手刹（暂存）、脚刹（提交），git diff就是每次踩下前的仪表盘读数。跳过任何一个，都意味着你放弃了对代码状态的主动控制权。

2.3 为什么“比较两个 commit”是所有高级分析的起点？

git diff commit-A commit-B看似只是基础命令的延伸，但它触发的是 Git 最底层的树对象（tree object）比对机制。当你运行git diff main feature/login，Git 实际在做：

• 解析main分支指向的 commit 对象，获取其 root tree hash；
• 解析feature/login分支指向的 commit 对象，获取其 root tree hash；
• 递归比对两个 tree 对象下的所有 blob（文件内容）和 subtree（子目录）；
• 对于同名文件，调用git diff内部算法生成 patch；
• 对于新增/删除文件，直接标记状态。

这意味着：所有分支对比、PR 审查、版本发布差异报告，底层都是这个命令在驱动。如果你不理解git diff A B如何工作，你就无法真正读懂 CI/CD 系统生成的 diff 报告，也无法在代码评审中精准指出“这个函数的修改影响了缓存策略，需要同步更新测试用例”。

3. 核心细节解析与实操要点：从终端输出读懂每一行背后的代码故事

3.1 解剖git diff输出：不只是+和-，而是时空坐标系

我们回到那个analysis.py的修改案例。当git diff输出：

diff --git a/analysis.py b/analysis.py index db0e049..a7a7ab0 100644 --- a/analysis.py +++ b/analysis.py @@ -5,3 +5,6 @@ def analyze_data(data): return data.describe() +def visualize_data(data): + return data.plot(kind='bar') +

这八行信息，每一行都是关键线索：

1. diff --git a/analysis.py b/analysis.py：
   a/和b/不是随意前缀。a/代表“original”（原始状态），b/代表“modified”（修改后状态）。在git diff --staged中，a/是HEAD的文件，b/是暂存区的文件；在git diff main feature中，a/是main分支的文件，b/是feature分支的文件。永远记住：左边是“基准”，右边是“目标”。

2. index db0e049..a7a7ab0 100644：
   db0e049是原文件的 SHA-1 哈希前缀，a7a7ab0是新文件的 SHA-1 哈希前缀。100644是 Unix 文件权限（普通文件）。这个哈希值就是 Git 的“数字指纹”。如果两个文件哈希相同，Git 就认定内容完全一致，不会生成任何 diff 行。这也是为什么git diff速度极快——它先比哈希，再比内容。

3. --- a/analysis.py和+++ b/analysis.py：
   这是 GNU diff 标准格式的标识。---后跟原始文件路径（含时间戳，Git 通常省略），+++后跟目标文件路径。注意：这里的路径是逻辑路径，不是物理路径。a/analysis.py意味着“在基准状态中，这个文件叫 analysis.py”，与你当前工作目录的路径无关。

4. @@ -5,3 +5,6 @@（hunk header）：
   这是最易被误解也最关键的行。-5,3表示：在原始文件中，从第 5 行开始，取 3 行作为上下文（context lines）；+5,6表示：在目标文件中，从第 5 行开始，取 6 行作为上下文。
   为什么行数变了？因为新增了 3 行代码（+def visualize_data...），所以目标文件的上下文范围扩大了。Git 的 hunk 设计原则是：尽可能包含足够的上下文，让人类能准确定位修改位置，同时最小化冗余。默认的 3 行上下文（-U3）是经过大量实践验证的平衡点——太少（如-U1）会导致多个 hunk 合并成一个大块，难以分辨；太多（如-U10）则淹没重点。

5. 内容行中的符号含义：

   • （空格）：该行在原始和目标文件中都存在，是上下文（context）；
   • +：该行仅存在于目标文件（新增）；
   • -：该行仅存在于原始文件（删除）；
   • +和-行严格按顺序排列，形成“变化流”。例如，-return data.describe()后紧跟+return data.describe().round(2)，清晰表明这是同一逻辑的修改，而非删除旧函数再新建。

实操心得：我曾遇到一个团队因git diff默认的-U3上下文，在重构一个长函数时，把两个相距 10 行的修改（一个改参数，一个改返回值）合并到了同一个 hunk 里，导致 Code Review 时误以为是原子操作。后来我们统一约定：对核心业务函数，git diff -U5是强制要求。多出的两行上下文，换来了 100% 的修改意图识别率。

3.2 路径限定：如何在千个文件的仓库里，一秒锁定关键变更？

大型项目中，git diff默认输出可能长达数百屏。盲目滚动是低效的。Git 提供了精准的“手术刀式”过滤：

• 单文件聚焦：git diff config.txt
  直接跳过所有其他文件，只显示config.txt的差异。适用于：修改了配置文件后，只想确认LOG_LEVEL=INFO是否生效，而不关心其他模块。

• 目录级过滤：git diff -- src/utils/
--是 Git 的路径分隔符，明确告诉 Git：“后面的内容是文件路径，不是分支名或 commit hash”。src/utils/会匹配该目录下所有文件（包括子目录）。适用于：前端项目中，只想看utils/目录下的工具函数是否有 API 变更。

• 通配符匹配：git diff -- "*.py"
  注意引号！防止 shell 提前展开*.py。这会匹配所有 Python 文件。适用于：Python 项目升级pandas版本后，快速扫描所有.py文件中pd.read_csv的调用是否需要适配新 API。

• 排除特定文件：git diff -- . ':!README.md'
:!是 Git 的路径排除语法。.表示当前目录所有文件，':!README.md'表示排除README.md。适用于：提交前想检查所有代码变更，但README.md的更新是纯文档，无需代码审查。

注意：路径过滤是在 diff 计算完成后进行的裁剪，不是提前跳过文件读取。所以对超大仓库，git diff -- large_binary_file.dat依然会卡顿——因为 Git 还是得先读取并哈希这个大文件。此时应配合--no-ext-diff或直接git diff --name-only先看文件列表。

3.3 上下文控制：-U<n>不是炫技，而是认知效率的杠杆

默认的-U3（3 行上下文）在大多数场景下足够好，但有两类情况必须调整：

场景一：算法/数学逻辑密集型代码
假设你在修改一个统计函数：

# 原始 def calculate_score(data): score = 0 for item in data: score += item.value * item.weight return score / len(data) # 修改后 def calculate_score(data): if not data: return 0 score = 0 for item in data: score += item.value * item.weight * item.bonus_factor # 新增因子 return score / max(len(data), 1) # 防除零

用-U3的 diff 会是：

@@ -1,6 +1,8 @@ def calculate_score(data): + if not data: + return 0 score = 0 for item in data: - score += item.value * item.weight + score += item.value * item.weight * item.bonus_factor return score / len(data) + return score / max(len(data), 1)

问题在于：return score / len(data)和return score / max(len(data), 1)被分隔在两个 hunk，你无法一眼看出这是对同一行的修改（防除零）。此时git diff -U5会把整个函数体纳入一个 hunk，清晰展示“原逻辑被包裹在条件判断中，并修改了分母”。

场景二：超长配置文件或 SQL 脚本
一个 500 行的schema.sql，只改了第 420 行的一个字段类型。-U3会生成 40+ 个 hunk，每个 hunk 只有 3 行，你需要滚动半天才能找到目标。而git diff -U1会把所有变更压缩成最少的 hunk 数量，虽然牺牲了部分上下文，但极大提升了“找到变更点”的速度。

实操心得：我的终端 alias 是alias gd='git diff -U5'和alias gds='git diff --staged -U5'。多出的 2 行上下文，几乎从不增加阅读负担，却总能在关键时刻让你看清“这一行修改，到底影响了哪段逻辑分支”。

4. 实操过程与核心环节实现：手把手构建数据项目，用 diff 驱动每一次代码演进

4.1 初始化与基线建立：让git diff从第一天就成为你的习惯

我们创建一个真实的、有业务意义的数据分析项目，而不是玩具仓库。这能暴露真实世界中的 diff 复杂性（如 CSV 数据变更、配置文件格式化、依赖版本更新）。

# 创建项目并初始化 mkdir -p ~/projects/data-analysis-project && cd ~/projects/data-analysis-project git init # 创建具有真实业务语义的初始文件 cat > README.md << 'EOF' # 用户行为分析平台 实时监控用户点击、停留、转化路径，为产品迭代提供数据支持。 ## 核心指标 - 页面平均停留时长 (AVG_SESSION_DURATION) - 关键按钮点击率 (CTA_CLICK_RATE) - 新用户次日留存率 (NEW_USER_RETENTION_DAY2) EOF cat > requirements.txt << 'EOF' pandas==1.5.3 numpy==1.24.1 matplotlib==3.7.0 EOF cat > config.yaml << 'EOF' # 数据源配置 data_sources: - name: web_logs path: ./data/web_logs.parquet format: parquet - name: user_profiles path: ./data/user_profiles.csv format: csv # 分析参数 analysis: window_days: 30 min_sample_size: 1000 outlier_threshold: 3.0 EOF # 创建模拟数据（CSV 格式，便于观察 diff） cat > data/web_logs.csv << 'EOF' timestamp,user_id,event_type,page_url,duration_sec 2023-10-01T08:30:00Z,u123,click,/home,120 2023-10-01T08:32:15Z,u123,view,/product/abc,240 2023-10-01T08:35:45Z,u456,click,/about,60 EOF # 创建核心分析脚本 cat > src/analyzer.py << 'EOF' import pandas as pd def load_web_logs(file_path): """加载网页日志数据""" return pd.read_csv(file_path) def calculate_avg_session_duration(logs_df): """计算平均会话时长""" return logs_df['duration_sec'].mean() if __name__ == "__main__": logs = load_web_logs("./data/web_logs.csv") avg_duration = calculate_avg_session_duration(logs) print(f"平均会话时长: {avg_duration:.2f} 秒") EOF # 第一次提交：建立基线 git add . git commit -m "chore: 初始化用户行为分析平台 v0.1"

关键动作与git diff验证：

• 执行git status后，立刻运行git diff --stat。你会看到：

  README.md | 6 ++++++ config.yaml | 12 ++++++++++++ data/web_logs.csv | 4 ++++ requirements.txt | 3 +++ src/analyzer.py | 13 +++++++++++++ 5 files changed, 38 insertions(+)

  这个--stat输出是你的“项目健康快照”——它确认了所有 5 个文件都被正确跟踪，且没有意外的空白行或编码问题（那些+号就是新增行数）。

• 运行git diff --name-only，确认只有这 5 个文件被修改。如果有__pycache__/或.DS_Store出现，说明.gitignore没配好，需立即修正。

4.2 模拟真实开发流程：用git diff指导渐进式重构

现在，我们模拟一个典型需求：“支持从 Parquet 格式加载日志，提升大数据量下的 I/O 性能”。这涉及多文件协同修改，git diff是唯一的协调员。

步骤 1：修改配置文件，声明新数据源

# 编辑 config.yaml，添加 parquet 支持 sed -i '' '/web_logs:/a\ format: parquet' config.yaml # macOS 用户用 sed -i ''，Linux 用户用 sed -i

步骤 2：修改分析脚本，增加 Parquet 加载逻辑

# 在 analyzer.py 中插入新函数 sed -i '' '/def load_web_logs/a\ def load_web_logs_parquet(file_path):\ """加载 Parquet 格式日志数据（高性能）"""\ return pd.read_parquet(file_path)\ ' src/analyzer.py # 修改主函数，根据配置选择加载方式 sed -i '' '/if __name__ ==/i\ import yaml\ with open("config.yaml") as f:\ config = yaml.safe_load(f)\ data_source = config["data_sources"][0]\ if data_source["format"] == "parquet":\ logs = load_web_logs_parquet(data_source["path"])\ else:\ logs = load_web_logs(data_source["path"])\ ' src/analyzer.py

步骤 3：准备 Parquet 数据（模拟）

# 将 CSV 转为 Parquet（需要 pyarrow） python -c "import pandas as pd; df=pd.read_csv('data/web_logs.csv'); df.to_parquet('data/web_logs.parquet')" # 删除旧的 CSV，只保留 Parquet（体现真实数据迁移） rm data/web_logs.csv

现在，用git diff进行三次关键审查：

1. 审查未暂存变更 (git diff)：
   你会看到config.yaml的格式变更、src/analyzer.py的函数新增和主逻辑修改、data/web_logs.parquet的二进制变更（显示为Binary files a/data/web_logs.parquet and b/data/web_logs.parquet differ）。
   关键发现：data/web_logs.csv被删除了，但git diff没显示删除行！因为rm操作后，该文件已不在工作区，Git 无法读取其内容进行比对。此时git status会显示deleted: data/web_logs.csv，提醒你git add -u来暂存删除操作。

2. 暂存并审查待提交内容 (git add . && git diff --staged)：
   运行git add .后，git diff --staged会清晰显示：

   • config.yaml：新增了format: parquet行；
   • src/analyzer.py：新增了load_web_logs_parquet函数，以及if/else加载逻辑；
   • data/web_logs.parquet：标记为new file mode 100644；
   • data/web_logs.csv：标记为deleted file mode 100644。
     这就是你即将提交的完整契约。如果这里看到print("DEBUG")或调试用的import pdb，立刻git restore回滚。

3. 最终提交 (git commit -m "feat: 支持 Parquet 格式日志加载")：
   提交后，立刻运行git show --stat（等价于git diff HEAD^ HEAD --stat）。它会显示本次提交的净效果：+1行在config.yaml，+12行在analyzer.py，+1个新文件，-1个删除文件。一个健康的提交，其--stat输出应该讲述一个连贯的故事。如果它显示+500 -10，那大概率是混入了格式化变更，需要拆分。

4.3 高级技巧实战：用git diff进行精准的“代码考古”

当线上出现一个诡异 bug，而错误日志只指向src/analyzer.py的某一行时，git diff是你的考古铲。

场景：calculate_avg_session_duration函数突然返回NaN
我们怀疑是某个 commit 引入了空数据处理缺陷。

1. 用git log -p追溯函数变更史：

   git log -p -S"def calculate_avg_session_duration" -- src/analyzer.py

   -S（pickaxe）选项会搜索所有 commit 中，新增或删除了包含该字符串的行。它会列出所有修改过这个函数定义的 commit，并附带当时的完整 diff。你很快会发现，一个名为refactor: improve error handling的 commit，在函数开头加了一行if logs_df.empty: return 0，但忘了处理logs_df['duration_sec']为空的情况。

2. 用git bisect定位引入点：
   如果git log -p没有直接答案（比如 bug 是由多个小修改累积导致），启动二分查找：

   git bisect start git bisect bad # 当前 HEAD 有 bug git bisect good v0.1 # 已知 v0.1 版本正常 # Git 自动检出中间 commit，你运行测试脚本 python src/analyzer.py # 观察是否返回 NaN # 如果有 bug，执行 git bisect bad；如果没有，执行 git bisect good # 重复直到 Git 找到第一个坏 commit git bisect log # 查看整个 bisect 过程

3. 用git diff审视罪魁祸首：
   当git bisect锁定 commitabc123后，执行：

   git diff abc123^ abc123 -- src/analyzer.py

   这会精确显示abc123这个 commit相对于其父 commit 的唯一变更。你可能会看到：

   @@ -10,6 +10,7 @@ def calculate_avg_session_duration(logs_df): + if logs_df.empty: + return 0 return logs_df['duration_sec'].mean()

   问题暴露：mean()在空 Series 上返回NaN，而if logs_df.empty只检查了 DataFrame 是否为空，没检查duration_sec列是否为空。修复方案呼之欲出：if logs_df.empty or logs_df['duration_sec'].empty:。

实操心得：我处理过一个生产事故，git bisect在 1200 个 commit 中，仅用 11 次测试就定位到问题。关键不是 bisect 本身，而是git diff让我在定位后的 30 秒内，就看懂了问题根源。没有git diff，bisect 只是一把钝刀。

5. 常见问题与排查技巧实录：那些官方文档不会写的“血泪教训”

5.1 问题：git diff显示“Binary files differ”，但我需要看到具体内容！

原因：Git 默认将非文本文件（图片、PDF、编译产物、数据库文件）视为二进制，只报告“不同”，不尝试解析内容。这是性能优化，但有时你需要“透视”。

解决方案：

• 方法一：强制文本化（谨慎！）
  git diff --textconv -- <file>。前提是你的 repo 配置了textconv过滤器。例如，为 PDF 添加文本提取：

  # 在 .gitattributes 中添加 *.pdf diff=pdf # 在 .git/config 中添加 [diff "pdf"] textconv = pdftotext -layout -q

  然后git diff就会显示 PDF 的文本内容（布局保持）。

• 方法二：用外部工具
  git difftool -t vimdiff --no-symlinks <file>。vimdiff能以十六进制模式打开二进制文件，让你手动比对字节差异。对.so或.dll文件调试非常有用。

• 方法三：转换为可 diff 格式
  对于 JSON/YAML 配置，用jq或yq格式化后再 diff：

  git show HEAD:config.json | jq -S . > /tmp/old.json git show HEAD~1:config.json | jq -S . > /tmp/new.json diff /tmp/old.json /tmp/new.json

注意：永远不要对生产数据库文件（如 SQLite.db）直接git diff。它们是真正的二进制，强行解析会损坏。正确的做法是导出为 SQL 文本再 diff。

5.2 问题：git diff输出乱码，中文显示为M-oM-?M-?

原因：Git 默认使用 UTF-8 编码，但你的终端或文件可能用了 GBK、ISO-8859-1 等编码。Git 无法自动检测。

解决方案：

• 全局设置 Git 使用 UTF-8（推荐）：

  git config --global core.autocrlf input git config --global core.precomposeunicode true # macOS 用户

• 为特定文件指定编码：
  在.gitattributes中添加：

  *.txt text working-tree-encoding=UTF-8 *.md text working-tree-encoding=UTF-8

• 临时解决：在 diff 命令中指定编码（Linux/macOS）：
  git diff | iconv -f GBK -t UTF-8

5.3 问题：git diff --staged什么也不显示，但git status说有修改！

原因：最常见的是文件权限变更（如chmod 755 script.sh）。Git 默认不跟踪权限，除非你设置了core.filemode true。

排查步骤：

1. git status -v：查看详细状态，权限变更会显示old mode 100644 / new mode 100755；
2. git diff --no-index /dev/null script.sh：强制比较空文件和当前文件，会显示权限行；
3. git config core.filemode false：如果项目不依赖权限，关闭此选项，避免干扰。

另一个原因：文件被.gitignore忽略，但你用git add -f强制添加了。此时git diff --staged会显示，但git status不会提示“已暂存”。用git ls-files -o -i --exclude-standard查看被忽略的文件。

5.4 问题：git diff太慢！在大型仓库中卡住超过 10 秒

根因分析：git diff慢通常有三个来源：

• 大文件：单个文件 > 10MB，Git 需要完整读取并哈希；
• 大量文件：git status已经很慢，git diff更甚；
• 子模块：Git 会递归进入每个子模块执行 diff。

提速方案：

• 排除大文件：git diff -- . ':!large_dataset.bin'；
• 限制文件数量：git diff --name-only | head -20 | xargs git diff（先看前 20 个文件的 diff）；
• 禁用子模块：git diff --no-submodules；
• 终极方案：用git status --porcelain=v2替代：它输出机器可读的简短状态，速度是git diff的 10 倍，适合 CI/CD 脚本判断是否有变更。

5.5 问题：如何用git diff审查别人的 PR？（团队协作黄金法则）

在 GitHub/GitLab 上，PR 页面的 diff 是git diff的 Web 封装。但 CLI 的git diff提供了更强大的能力：

• 下载 PR 的 diff 并本地审查：

  # 获取 PR 的 patch（GitHub API） curl -s "https://api.github.com/repos/OWNER/REPO/pulls/123" | jq -r '.diff_url' | xargs curl -s > pr-123.patch # 应用 patch 到本地分支，然后用你熟悉的工具审查 git apply pr-123.patch git difftool -t vscode

• 审查 PR 中特定文件的变更：
  git fetch origin pull/123/head:pr-123 && git diff main pr-123 -- src/core/algorithm.py。这比在网页上滚动更高效。

• 自动化审查：在 CI 中加入git diff --check，它会报告所有 trailing whitespace 和混合 tab/spaces 的行，强制代码风格统一。

我的团队规定：任何超过 50 行的 PR，必须在本地git difftool审查后，再点击 “Approve”。这避免了“网页上扫一眼就通过”的草率，将 Code Review 的质量提升了 70%。git diff不是命令，是责任。

6. 工具链与工作流整合：让git diff成为你编辑器的呼吸节奏

6.1 VS Code 深度集成：不只是git difftool

VS Code 的 Git 扩展远不止git difftool。它把git diff的能力无缝注入日常编码：

• 行内差异指示器：编辑器左侧的“变更栏”（Gutter）会用绿色/红色/蓝色条，实时显示当前文件相对于HEAD的新增、删除、修改行。这是最常被忽视的 diff 功能——它让你在写代码时，就感知到“我正在偏离基线”。

• Staging 面板：Ctrl+Shift+P->Git: Stage Selected Ranges，可以只暂存文件中的某几行（Hunk），而不是整个文件。这完美支持“逻辑分组提交”。例如，你改了一个函数的 bug 修复（3 行）和一个无关的文档更新（2 行），可以分别暂存，提交两次。

• Time Travel Debugging：右键点击任意一行 ->Git: Compare with Previous Revision。它会调用git diff，显示这一行在上一个 commit 中的样子。重构时，这是验证“我是否改对了”的最快方式。

6.2 终端效率提升：Alias 与 Shell 函数

把高频git diff操作封装成一句话命令：

# ~/.zshrc or ~/.bashrc # 快速查看暂存区变更（带高亮和 5 行上下文） alias gds='git diff --staged --color-