📚 课程目录第4章基本操作

基本操作：git add, git commit, git status, git log

这四个命令，是 Git 日常用得最多的「四件套」。我刚开始用 Git 的时候，觉得不就是个版本管理嘛，记几个命令就行了。结果呢？有一次急着下班，直接 git commit 发现没加文件——嗯，空提交。从那以后我再也不敢小看这几个基础命令了。

说白了，它们管的是「把代码从工作区搬到仓库」的整个流程。你想想看，写代码就像盖房子，你得先备料、搬砖、砌墙，最后签个名标注这是第几层。Git 也一样：git status 是查看工地现状，git add 是把砖搬到暂存区，git commit 是真正砌好并挂上铭牌，git log 是翻看谁在什么时候干了什么。

1. git status —— 你的「现场监控器」

每次想操作之前，我习惯先敲 git status。它告诉你三件事：哪些文件被改了，哪些已经准备好了，哪些还没被 Git 追踪。

git status

输出大概是这样的：

On branch main
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git restore ..." to discard changes in working directory)
        modified:   src/main.py

Untracked files:
  (use "git add ..." to include in what will be committed)
        docs/readme.md

红色表示未暂存，绿色表示已暂存。我曾经浪费过半小时在找文件为什么不提交，后来发现只是忘了 git add——你想想看，git status 一眼就能看出来。

个人习惯：我每次 commit 前都会先跑 git status，确认只包含我想要的文件。尤其是团队协作时，一个不小心就把调试日志或者 IDE 配置给带进去了。

2. git add —— 把「待办」变成「已办」

git add 是把工作区的改动添加到暂存区（也叫索引）。像打包行李——你先挑好哪些东西要带走。

# 添加单个文件
git add src/main.py

# 添加所有改动（慎用）
git add .

# 添加当前目录下的所有改动
git add -A

有经验的人会告诉你：别总用 git add .。为什么？因为可能把不该提交的东西也加进去了，比如临时文件、日志、密钥。我曾在项目里不小心把 .env 文件加了进去，推到了远程仓库…… 那叫一个酸爽。

避坑指南：我曾经把公司 API 密钥提交到公开仓库里，虽然及时撤销了，但还是吓得一身冷汗。现在我会在项目根目录建好 .gitignore，把敏感文件和构建产物提前排除。

如果你只想添加部分改动的行，也可以用交互模式：

git add -p

它会逐块询问你是否暂存，非常适合只提交某个功能的改动，而把调试代码留在工作区。

3. git commit —— 给历史打个「快照」

暂存区准备好了，就该 git commit 了。我习惯用 -m 参数直接在命令行写消息：

git commit -m "fix: 修复登录页面超时处理"

如果消息太长，或者想写详细描述，可以不加 -m：

git commit

它会打开默认编辑器（比如 Vim 或 VS Code），让你写多行提交信息。我个人推荐第一行简明扼要，空一行，再写补充说明。

提交信息写得好不好，直接影响后期查 bug 的效率。我见过有人只写 update 或 fix bug，三个月后他自己都看不懂改了啥。我的建议是：用 约定式提交格式：

<类型>(范围): <描述>

可选：正文详细说明
可选：关闭 issues #123

类型	使用场景
feat	新功能
fix	修复 bug
docs	文档变更
refactor	重构代码
chore	构建或其他杂项

  小技巧：如果 commit 后发现有遗漏，可以用 git commit --amend 修正上一次提交。注意：如果已经推到了远程，就要用 --force-with-lease 来覆盖，但团队协作时一定要确认没人基于那个 commit 工作。

4. git log —— 翻开「项目日记」

想看历史提交？git log 是必须的。默认输出很长，但很清晰：

git log

commit a1b2c3d4e5f6...
Author: Zhang San 
Date:   Mon Jan 15 10:00:00 2024 +0800

    fix: 修复登录页面超时处理

commit f6e5d4c3b2a1...
Author: Li Si 
Date:   Sun Jan 14 17:30:00 2024 +0800

    feat: 添加用户资料编辑功能

我常用的几种 git log 变体：

git log --oneline —— 每行只显示 commit hash 和标题，干净利落
git log --graph —— 显示分支和合并历史，画成一棵树
git log --author="张三" —— 只看某人的提交
git log -3 —— 只看最近 3 次提交

说实话，我第一次看 git log --graph 时觉得挺酷的——那些星号和斜线能把分支关系画得明明白白。

避坑提醒：如果你想把日志保存下来，可以配合 --pretty=format:"%h %s" 自定义输出格式。比如写 changelog 时我就用 git log --oneline --since="2024-01-01" --until="2024-02-01" 来筛选某段时间的提交。

5. 四者联动的完整流程

它们组合起来就是 Git 的「核心工作流」：

修改文件（工作区）
git status 查看状态
git add <文件> 暂存改动
git commit -m "描述" 提交快照
git log 确认提交记录

下面这张图概括了数据流转：

  记住这个口诀：改完代码先 status，add 之后才 commit，log 一看心里有数。

我个人习惯每天上班第一件事就是 git status 和 git log --oneline -5，快速了解自己和同事昨天做了什么。这个习惯帮我避免了很多冲突。

6. 常见误区总结

误区	正确做法
`git add .` 后直接 commit，从不查看 status	先 `git status` 确认只包含必要文件
commit 后才发现漏了文件	用 `git add` 补上，然后 `git commit --amend` 合并到上次提交
写无意义的提交信息	坚持约定式提交，让同事（包括未来的自己）看懂
从不看 log，直接靠猜	养成 `git log --oneline --graph` 的习惯

我曾经犯的错：有一次提交前没按规范写信息，直接写了个 aa。后来项目复盘，我要从上百条 aa 里找出是哪个提交改了关键配置…… 嗯，至今难忘。从那以后，我所有项目的 commit 模板都强制要求类型 + 描述。

git add、git commit、git status、git log 这四个命令，虽然简单，但用好了能让你的版本管理井井有条。别偷懒，每次操作前多看两眼 status，写提交信息时多花十秒钟。相信我，未来的你会感谢现在的你。