3、Git核心操作：工作区、暂存区、仓库的概念，add、commit、status、log命令详解
好，咱们今天聊点实在的。Git 这东西，说白了就是帮咱们嵌入式团队管代码的。你想想看，一个项目几十个人，每个人改几行，没有 Git 那不乱成一锅粥？
我个人习惯，把 Git 理解成三个盒子。你往盒子里放东西，Git 帮你记着每一步。这三个盒子就是：工作区、暂存区、仓库。
3.1 三个核心概念：工作区、暂存区、仓库
工作区，就是你电脑上能看到的那堆文件夹和文件。你写代码、改代码，全在这里发生。说白了，就是你平时干活的地方。
暂存区，这个有点意思。它像一个临时中转站。你改完代码，觉得这版可以了，就先放到暂存区。但注意，这时候还没真正存到 Git 里。我刚开始用 Git 时，总搞混暂存区和仓库的区别。后来想明白了：暂存区就像你写草稿，仓库才是最终定稿。
仓库，就是 Git 真正存数据的地方。你所有提交的历史，全在这里。仓库又分本地仓库和远程仓库。本地仓库在你电脑上，远程仓库在服务器上（比如 GitHub、GitLab）。
核心理解：工作区是你改代码的地方，暂存区是你准备提交的地方，仓库是你存历史的地方。这三个地方，数据流动方向是：工作区 → 暂存区 → 仓库。
3.2 add 命令：把文件放入暂存区
git add 这个命令，就是把工作区的改动，放到暂存区。我见过很多新手，上来就 git commit，结果 Git 提示 nothing to commit。为什么？因为你忘了 git add。
常用的几种用法：
# 添加单个文件
git add main.c
# 添加所有改动
git add .
# 添加当前目录所有 .c 文件
git add *.c
# 交互式添加（推荐）
git add -p我个人特别喜欢 git add -p。它会把每个改动块（hunk）展示给你，问你要不要加。这样你可以只提交一部分改动，另一部分留着继续改。我在项目中遇到过，一个文件里既有 bug 修复，又有新功能开发。用 git add -p 就能把它们分开提交，方便后面回溯。
小技巧：用 git add -p 时，输入 y 表示添加这个改动块，n 表示跳过，s 可以拆分更细的改动块。多练几次就熟了。
3.3 commit 命令：把暂存区内容存入仓库
git commit 是把暂存区的内容，真正存到仓库里。每次 commit 都会生成一个唯一的哈希值，就像身份证号一样。
# 基本提交
git commit -m "修复了定时器溢出bug"
# 跳过暂存区，直接提交（仅对已跟踪文件有效）
git commit -a -m "更新了驱动代码"
# 修改最近一次提交
git commit --amend这里有个坑，我曾经踩过。有一次我改了一堆文件，然后 git commit -a -m "大更新"。结果发现把调试代码也提交上去了。为什么？因为 -a 只会提交已跟踪的文件，新文件它不管。但如果你改了已跟踪的文件，它就直接提交了，不会经过暂存区。
所以我的建议是：养成先 git add 再 git commit 的习惯。虽然多了一步，但能避免很多问题。
注意：commit 信息要写清楚。别写什么 "fix bug"、"update" 这种。我见过最离谱的是 "asdf"。你想想看，三个月后你回来看这个 commit，能想起来改了啥吗？
3.4 status 命令：查看当前状态
git status 是我用得最多的命令，没有之一。它告诉你：工作区有什么改动，暂存区有什么东西，有没有未跟踪的文件。
# 查看状态
git status
# 简洁模式
git status -sgit status -s 的输出很简洁。每行两个字母，第一个字母表示暂存区的状态，第二个表示工作区的状态。比如：
| 状态码 | 含义 |
|---|---|
| ?? | 未跟踪的新文件 |
| M | 已修改 |
| A | 已添加到暂存区 |
| D | 已删除 |
嗯，这里要注意。如果你看到 MM，表示这个文件在暂存区和工作区都有改动。这种情况挺常见的，你 git add 之后又改了文件。
3.5 log 命令：查看提交历史
git log 是查看提交历史的。默认会显示所有 commit，按时间倒序排列。
# 基本查看
git log
# 一行显示
git log --oneline
# 显示图形分支
git log --graph --oneline --all
# 显示某个文件的修改历史
git log --follow -p main.c我个人习惯用 git log --oneline --graph --all。这样能看到整个分支的脉络，谁在什么时候合并了谁，一目了然。我在项目中遇到过，有人把分支搞乱了，用这个命令一看，马上就知道问题出在哪。
git log --follow -p main.c 这个命令特别有用。它能显示某个文件的所有改动，包括重命名之前的。你想想看，如果有个 bug 是三个月前引入的，用这个命令就能找到是谁改的、为什么改。
避坑指南：我曾经在嵌入式项目里，用 git log 发现有人把编译生成的 .o 文件也提交了。这会导致仓库越来越大，而且每次编译都会产生冲突。所以一定要配好 .gitignore 文件。
3.6 实战：一个完整的操作流程
咱们来走一遍完整的流程。假设你在开发一个 STM32 的项目：
# 1. 查看当前状态
git status
# 2. 修改了 main.c 和 timer.c
# 3. 查看改动
git diff
# 4. 把 main.c 加入暂存区
git add main.c
# 5. 再次查看状态
git status -s
# 6. 提交
git commit -m "修复了定时器初始化顺序问题"
# 7. 查看提交历史
git log --oneline -3这个流程，我每天要重复几十遍。刚开始可能觉得麻烦，但习惯了就会发现，它让你对代码的每一次改动都心中有数。
我的习惯：每次提交前，先用 git diff --cached 看看暂存区里到底要提交什么。确认无误后再 commit。这一步能避免很多低级错误。
好了，Git 的核心操作就这些。记住三个区、四个命令。工作区改代码，暂存区准备提交，仓库存历史。add 放进去，commit 存起来，status 看状态，log 查历史。就这么简单。
下一章咱们聊分支操作。分支这东西，在嵌入式团队里用好了，能省不少事。