3、Git基本操作：git init、git clone、git add、git commit、git status、git log、git diff

好，咱们进入正题。这一章讲的是Git最核心的七个命令。说白了，你日常工作中90%的时间都在跟它们打交道。我见过不少新人，一上来就折腾分支、合并、rebase，结果连最基本的提交都写不明白。嗯，咱们先把地基打牢。

3.1 git init：从零开始建仓库

你拿到一个新项目，或者想把本地一个文件夹纳入版本管理，第一件事就是跑 git init。这个命令会在当前目录下创建一个隐藏的 .git 文件夹，里面装着Git需要的所有元数据。

cd /home/adas_ws/perception_module
git init

跑完之后，你会发现终端里没输出什么花哨的东西。别慌，这就成了。我个人习惯在初始化之后立刻看一眼状态：

git status

它会告诉你「On branch master」或者「On branch main」，然后一堆「Untracked files」。这很正常，因为你还没告诉Git要管哪些文件。

3.2 git clone：把远程仓库拉到本地

这个更常见。团队里肯定有一个远程仓库（GitHub、GitLab、或者自建的Gitea）。你不需要从头 init，直接克隆就行。

git clone git@gitlab.adas-team.com:perception/lidar_fusion.git

克隆下来之后，你本地就有了完整的仓库，包括所有历史记录和所有分支。我记得有一次，新同事问我：「为什么我克隆完只有master分支？」其实所有远程分支都在，只是本地没建跟踪分支而已。用 git branch -r 就能看到。

3.3 git add：把改动放进暂存区

你改完了代码，想提交。但Git不会自动跟踪你的修改，你得先告诉它：「这些文件我要提交」。这就是 git add 的作用。

git add src/lidar_driver.cpp
git add include/lidar_driver.h

你也可以一次性加所有改动：

git add .

但说实话，我不建议你这么干。你想想看，万一你改了一个调试用的临时文件，或者不小心生成了一个巨大的日志文件，git add . 会把它们全塞进去。我习惯用 git add -p，它会逐块询问你是否要暂存。这样我能仔细检查每一处改动，避免把调试代码带进正式提交。

3.4 git commit：把暂存区的内容正式记录

这是最关键的一步。暂存区里的东西，通过 git commit 变成一次历史记录。

git commit -m "fix: 修复激光雷达点云畸变问题"

我个人强烈建议你写有意义的提交信息。别写什么「update」、「fix bug」、「改了东西」这种废话。你想想，三个月后你回来查一个bug，看到「改了东西」，你是什么心情？

我一般遵循 Conventional Commits 规范：

类型	含义	示例
feat	新功能	feat: 添加AEB紧急制动逻辑
fix	修复bug	fix: 修正车道线检测中的内存泄漏
refactor	重构	refactor: 重构传感器融合模块接口
docs	文档	docs: 更新CAN总线通信协议说明
test	测试	test: 添加目标跟踪单元测试

3.5 git status：随时查看当前状态

这个命令我一天能跑几十次。它告诉你三件事：

• 哪些文件被修改了但还没暂存（红色）
• 哪些文件已经暂存了但还没提交（绿色）
• 当前在哪个分支上

git status

输出大概长这样：

On branch feature/lane_detection
Changes not staged for commit:
  modified:   src/lane_detector.cpp
  modified:   include/lane_detector.h

Untracked files:
  test_data/road_scene.bin

嗯，看到那个 test_data/road_scene.bin 了吗？二进制文件，不该被跟踪。赶紧加到 .gitignore 里。

3.6 git log：查看提交历史

你想知道这个项目经历了什么？用 git log。

git log --oneline --graph --all

这个组合拳我特别喜欢。--oneline 让每次提交只显示一行，--graph 画出分支拓扑，--all 显示所有分支。一眼就能看出谁在哪个分支上干了什么。

输出示例：

* 3a1b2c4 (HEAD -> feature/lane_detection) feat: 添加弯道曲率计算
* 8f7e6d5 fix: 修正直道检测误报
| * 2c3d4e5 (main) chore: 更新依赖库版本
|/  
* 1a2b3c4 init: 初始化车道线检测模块

你看，分支关系一目了然。我经常用这个来追溯某个bug是什么时候引入的。找到那个提交，然后 git show <commit-id> 看看具体改了啥。

3.7 git diff：看看你到底改了啥

提交之前，我建议你务必看一眼改动内容。用 git diff。

git diff

它会显示工作区（还没暂存）的改动。如果你想看暂存区跟上次提交的差异：

git diff --cached

我遇到过好几次这种情况：觉得自己改得没问题，结果 git diff 一看，发现多了一个调试用的 printf，或者某个变量名拼写错了。嗯，这个习惯救了我很多次。

说白了，这七个命令就是Git的「呼吸」和「心跳」。你每天的工作流就是在这几个命令之间循环。别小看它们，我见过不少资深工程师，提交信息写得乱七八糟，或者动不动就把不该提交的文件塞进去。基本功扎实了，后面的分支、合并、冲突解决才能玩得转。

下一章咱们聊聊分支管理。你想想看，ADAS团队里同时开发感知、规划、控制三个模块，没有分支管理，那不乱成一锅粥？