Git Status：自信跟踪项目中的更改

如何使用 Git Status

以下是将 git status 高效融入您工作流的分步方法。

如果您尚未配置 Git，这份设置指南将带您完成跨平台的安装与初始配置。

git status 的基本用法

• 打开终端：

使用您偏好的终端或命令行界面。这样您就能直接运行 Git 命令，并实时查看仓库状态。

• 进入项目目录：

使用 cd 命令切换到您的 Git 项目所在的文件夹。

cd /path/to/your/project技术支持

• 运行 git status：

进入项目目录后，运行以下命令。

git status技术支持

如前所述，Git 通常会返回以下内容：

• 当前分支名称。
• 已暂存、可提交的更改列表。
• 已修改但未暂存的文件列表。
• 任何未跟踪的文件——尚未被 Git 添加的新文件。

使用简短格式

如果您需要快速查看而不想要额外细节，简短格式会很有用：

git status --short技术支持

这种精简视图将每个文件列在一行，并附带状态符号，特别适合在查找特定更改或将该命令集成进脚本时使用。

示例输出：

 M index.html
A  new-script.js
?? temp.txt技术支持

解读输出：

• 第一个字符表示暂存区状态。
• 第二个字符表示工作目录状态。

理解 git status 中的 -u 选项

-u 选项（--untracked-files 的缩写）可控制输出中未跟踪文件的显示方式，这在含有大量生成文件的项目中尤为相关。各模式含义如下：

• normal（默认）

以标准且节省空间的格式显示未跟踪文件。

示例：

git status -u normal技术支持

这是大多数开发者运行 git status 时所见的默认行为。

• all

列出所有未跟踪文件——即使是默认忽略的那些。

示例：

git status -u all技术支持

该模式提供完全可见性，在调试文件生成问题或审查通过 .gitignore 排除的内容时很有帮助。

• no

隐藏未跟踪文件，让您只关注 Git 已跟踪文件的更改。

示例：

git status -u no技术支持

在我的一个大型项目中——一个构建流程复杂的 Node.js 应用——git status 的输出被临时文件、缓存和构建产物所干扰。添加 -u no 选项让我能够专注于已跟踪文件的更改，而不被临时或自动生成的文件分散注意力。

用 --porcelain 自定义输出

对于脚本或自动化任务而言，可预测的输出至关重要。--porcelain 选项提供了干净、稳定、机器可读的 git status 输出，非常适合用于自定义工具或 CI/CD 工作流：

git status --porcelain技术支持

该模式模仿简短格式（--short），但保证在不同 Git 版本和配置之间输出一致。不像默认的 git status 会根据用户设置包含额外的空行、提示或颜色，--porcelain 会剥离所有此类格式——确保脚本能可靠地解析输出。

运行 Git Status 之后的下一步

运行 git status 并分析输出后，接下来就该决定您的下一步——是暂存文件、提交更新，还是清理工作目录。以下是具体做法。

为提交暂存文件

暂存会为下一次提交准备您的更改。您可以选择暂存单个文件，也可以一次性全部暂存。

• 暂存特定文件：

当您想精确控制要提交的内容时使用。

git add <file-name>技术支持

• 暂存所有更改：

包含当前目录中已修改及新添加的文件。

git add .技术支持

• 仅暂存已跟踪文件的更改（不包含新的未跟踪文件）：

git add -u技术支持

我建议在暂存前仔细使用 git status 或 git diff 审查更改，以避免意外包含不需要的文件。将 git status 与 git diff 命令 结合使用能更深入地了解文件中的更改。

提交更改

在暂存更改后，下一步就是创建一次提交。清晰且有描述性的提交消息不仅记录做了什么更改，也记录为什么要进行该更改——从而更容易在时间线上理解项目历史。

git commit -m "Describe your changes here"技术支持

提交信息最佳实践：

• 使用祈使语气（例如“修复登录 Bug”，而非“已修复登录 Bug”）。
• 尽量将摘要行控制在 50 个字符以内。
• 如有需要，使用多行信息（不带 -m 的 git commit）将摘要与详细说明分开。

我的经验是，多花一分钟写一条有意义的提交信息，能在后期审查或调试时节省无数时间。更改被审查后，不妨压缩提交（squash commits）以清理 Git 历史。

处理未跟踪文件

未跟踪文件可能使 git status 的输出变得杂乱，尤其是在包含构建产物、日志或依赖目录的项目中。如果存在您从不打算跟踪的文件或目录，可在仓库根目录添加 .gitignore 文件进行排除。

# Ignore dependency folders and log files
node_modules/
*.log

# Ignore system files
.DS_Store
Thumbs.db技术支持

这能确保仓库中只包含相关文件，使 git status 的输出保持干净、聚焦。当您需要从工作目录中移除残留的未跟踪文件时，git clean 也是不容错过的工具。

定期查看状态

经常运行 git status 是一个简单却强大的习惯，有助于保持干净且可控的开发工作流。通过定期检查工作目录与暂存区的状态——尤其是在提交、切换分支或合并之前——您可以避免如提交未完成更改或忽略未跟踪文件等常见错误。

我现在把这一步纳入日常流程，显著减少了提交历史中的错误。

排查常见的 Git Status 问题

即便它很简单，git status 的输出有时也会令人不知所措或感到困惑。以下是一些常见问题及其处理方法。

不需要的未跟踪文件

在大型项目中，尤其是使用各种构建工具的项目，您可能会看到许多并不想跟踪的文件。如果出现这种情况，请检查 .gitignore 设置，并在必要时使用以下命令将它们从跟踪中移除：

git rm --cached <file-name>技术支持

更新 .gitignore 并使用 git rm --cached 后，再次运行 git status 以确认该文件不再被跟踪或不再无谓地显示。

输出信息过多

在包含大量文件的项目中——尤其是会生成日志、缓存或临时资源的项目——git status 的输出可能会变得嘈杂且难以浏览。这会让您难以聚焦于需要关注的实质更改。

在这种情况下，您可以显示精简的“每个文件一行”的摘要：

git status --short技术支持

或者完全在输出中隐藏未跟踪文件：

git status -u no技术支持

结合使用这些选项，可以让 git status 更加聚焦、易于理解——尤其适用于大型代码库或自动化工作流。

结语

总之，git status 是一款不可或缺的工具，它为您提供了观测仓库健康状况的实时窗口。掌握其默认视图、简短格式以及 -u 等高级选项，能够帮助您优化 Git 工作流并避免常见陷阱。请在您的项目中尝试这些模式，体会在变更管理上的清晰度如何加速您的开发过程。

如果您是 Git 新手，将 git status 与初始化仓库的命令 git init 结合起来理解会更有力量。如果还没有，请查阅我的Git Init 教程，了解如何从零开始搭建一个仓库。

如果您还想进一步提升 Git 技能，不妨看看这些 DataCamp 课程：

• Intermediate Git —— 通过分支、合并与冲突解决技巧提升您的技能。
• GitHub Foundations —— 学习如何将 Git 与 GitHub 集成以开展协作项目。

祝您编码顺利——也祝您与仓库始终保持完美同步！