📚 课程目录第3章 Git核心操作

3、Git核心操作：git init, git clone, git add, git commit, git status, git log 实战演练

好，咱们直接进入正题。前面聊了版本控制的概念和 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，能一目了然地看到分支结构和提交顺序。在嵌入式项目里，特别是多人协作时，这个视图能帮你快速定位问题是在哪个分支引入的。

⚠️ 避坑指南： 我曾经在调试一个 I2C 驱动时，连续提交了 20 多次，每次都是“fix bug”。结果后来发现某个改动引入了新问题，想回退都找不到具体是哪个提交。从那以后，我坚持每次提交只改一个逻辑点，提交信息写清楚。

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 交互的基础。别急着背参数，先把流程跑通。多练几次，形成肌肉记忆。后面章节我们会在这个基础上，加入分支、合并、远程协作等更高级的操作。