3. Git环境搭建与配置
好，咱们直接进入正题。前面聊了版本控制的概念和 Git 的安装配置，今天这一章，我要带你亲手敲出 Git 的六个核心命令。这六个命令，说白了就是你日常工作中 90% 的时间都在用的东西。别小看它们，我见过不少老手，在这几个命令上翻过车。
3.1 创建仓库：git init 与 git clone
你要用 Git 管代码，首先得有个“仓库”。Git 提供了两种方式：从零新建，或者从远程复制。
3.1.1 git init：从零开始
当你有一个现成的项目文件夹，想把它纳入 Git 管理，就用 git init。我个人习惯，拿到一个新项目的第一件事，就是先跑这个命令。
cd /home/developer/embedded_project
git init执行后，Git 会在当前目录下创建一个隐藏的 .git 文件夹。这个文件夹就是 Git 的“心脏”，里面存着所有版本历史、配置和对象数据。你想想看，整个版本控制的核心，就藏在这个小文件夹里。
.git 文件夹里的内容。我曾经有个同事，为了“清理空间”直接删了 .git/objects，结果整个项目历史全丢了，最后只能从备份恢复。
3.1.2 git clone：从远程复制
如果你要参与一个已有的项目，或者想从 GitHub、GitLab 上拉代码，就用 git clone。它会自动把远程仓库完整地复制到本地，包括所有分支和历史。
git clone https://github.com/example/stm32-firmware.git这个命令会自动创建一个以项目名命名的文件夹（比如 stm32-firmware），然后初始化 .git，拉取所有数据。你拿到手就能直接开始工作。
| 命令 | 使用场景 | 结果 |
|---|---|---|
git init |
本地新建项目，从零开始 | 创建 .git 文件夹，仓库为空 |
git clone |
参与已有项目，从远程拉取 | 完整复制远程仓库到本地 |
3.2 记录变更：git add 与 git commit
仓库建好了，接下来就是记录你的工作成果。这两个命令是 Git 最核心的操作，也是新手最容易搞混的地方。
3.2.1 git add：把文件放进“暂存区”
你修改了代码，Git 能感知到，但它不会自动记录。你需要手动告诉 Git：“这些文件我要保存”。git add 就是把文件从工作区添加到“暂存区”（Staging Area）。
# 添加单个文件
git add main.c
# 添加所有改动的文件
git add .
# 添加当前目录下所有 .c 文件
git add *.c为什么要多一个“暂存区”？说白了，就是让你能精细控制每次提交的内容。比如你改了三个文件，但只想先提交两个，就可以只 git add 那两个。
git status 看一下哪些文件被改了，确认无误后再 git add。这样能避免把调试代码或临时文件不小心提交进去。
3.2.2 git commit：把暂存区的内容“拍个快照”
git commit 才是真正创建版本历史的操作。它会把暂存区里的所有改动，打包成一个“提交”（commit），并生成一个唯一的 SHA-1 哈希值作为标识。
# 提交并添加简短说明
git commit -m "修复了 UART 接收中断的溢出 bug"
# 提交并打开编辑器写详细说明
git commit提交信息一定要写清楚。我见过太多人写“fix bug”、“update”，过了一个月回头看，根本不知道改了啥。好的提交信息，应该能让别人（包括未来的你）一眼看懂这次改动的目的。
第一行：简短描述（50字以内）
空一行
正文：详细说明为什么改、怎么改、有什么影响
3.3 查看状态与历史：git status 与 git log
这两个命令是“只读”的，不会改变任何东西，但却是你每天用得最频繁的命令。
3.3.1 git status：随时掌握仓库状态
我敢说，git status 是我用得最多的命令，没有之一。它能告诉你：哪些文件被改了、哪些在暂存区、哪些还没被跟踪。
git status输出会清晰显示：
- Changes to be committed：已
git add，等待提交 - Changes not staged for commit：已修改，但没
git add - Untracked files：新文件，Git 还没管它
嗯，这里要注意：git status 只显示“有变化”的文件，没变化的它不会列出来。
3.3.2 git log：查看提交历史
想看看项目一路走来都经历了什么？git log 就是你的时光机。
# 查看完整历史
git log
# 一行显示，更简洁
git log --oneline
# 显示最近 3 条
git log -3
# 图形化显示分支合并历史
git log --graph --oneline --all我个人习惯用 git log --oneline --graph --all，能一目了然地看到分支结构和提交顺序。在嵌入式项目里，特别是多人协作时，这个视图能帮你快速定位问题是在哪个分支引入的。
3.4 核心工作流：一张图看懂
为了让你更直观地理解这几个命令之间的关系，我画了一张流程图。它展示了从工作区到远程仓库的完整数据流向。
3.5 实战演练：一个完整的嵌入式项目示例
光说不练假把式。咱们用一个真实的嵌入式项目场景，把六个命令串起来走一遍。
场景： 你正在开发一个 STM32 的 LED 闪烁程序，需要把代码纳入 Git 管理。
# 1. 创建项目目录并初始化仓库
mkdir led_blinker
cd led_blinker
git init
# 2. 创建 main.c 文件（假设内容已写好）
# 3. 查看仓库状态
git status
# 输出：Untracked files: main.c
# 4. 将 main.c 加入暂存区
git add main.c
# 5. 再次查看状态
git status
# 输出：Changes to be committed: new file: main.c
# 6. 提交第一个版本
git commit -m "初始提交：实现 LED 闪烁功能"
# 7. 查看提交历史
git log --oneline
# 输出：abc1234 初始提交：实现 LED 闪烁功能git init只做一次，项目开始时执行git add把改动放进暂存区，可以多次执行git commit把暂存区内容固化为一个版本git status随时查看当前状态，建议每次操作前都跑一次git log查看历史，帮你回顾项目演进
这六个命令，就是你与 Git 交互的基础。别急着背参数，先把流程跑通。多练几次，形成肌肉记忆。后面章节我们会在这个基础上，加入分支、合并、远程协作等更高级的操作。