3、Git核心操作：Git工作流程、常用命令与.gitignore配置
好，咱们进入正题。Git 这东西，说实话，刚入行那会儿我也觉得不就是个版本管理嘛，能有多复杂？直到有一次我在 ADAS 项目里，因为一个分支合并搞砸了，导致整个感知模块的代码回滚了两天。嗯，从那以后，我再也不敢小看 Git 了。
今天这节，我把 Git 最核心的操作给你捋一遍。你想想看，ADAS 系统里动辄几十个模块、上百号人同时开发，没有一套靠谱的版本管理流程，那简直就是灾难。
3.1 Git 工作流程：你每天都在用的那几条线
我个人习惯把 Git 工作流分成三个区域：工作区、暂存区、本地仓库。再加上一个远程仓库，一共四个地方。
核心流程一句话： 工作区改代码 → 暂存区挑文件 → 本地仓库做快照 → 远程仓库做备份。
在 ADAS 项目中，我们通常这样玩：
- 主分支（main/master）：只放稳定版本，每次合入都要经过 Code Review 和 CI 测试。
- 开发分支（develop）：日常开发的主战场，所有 feature 分支从这里拉出去，最后合回来。
- 功能分支（feature/*）：每个人干自己的活，比如 feature/lane_detection_v2。
- 修复分支（hotfix/*）：线上出了紧急 bug，直接从 main 拉分支修，修完马上合回去。
我记得有一次，我们团队在开发一个紧急的 AEB 功能优化，有人直接在 main 上改代码，结果把别人的改动覆盖了。从那以后，我强制要求所有人必须走 feature 分支流程。
3.2 常用命令：每天敲得最多的几个
命令不在多，够用就行。下面这几个，你每天都会用到。
3.2.1 clone：把远程仓库搬下来
git clone https://github.com/your-company/adas-system.git
cd adas-system这命令没啥好说的。但注意一点：如果项目里有 submodule（比如第三方感知库），记得加 --recursive 参数。
git clone --recursive https://github.com/your-company/adas-system.git小技巧： 我习惯在 clone 之后先看一眼分支情况：git branch -a。这样能知道远程有哪些分支，避免自己拉错了。
3.2.2 commit：给你的代码拍个快照
git add src/lane_detection.cpp
git commit -m "feat: 优化车道线检测算法，减少误检率"commit 消息怎么写？我建议你遵循 Conventional Commits 规范。说白了就是：
feat:新功能fix:修 bugdocs:文档refactor:重构test:测试
为什么要这么搞？因为后面做版本发布时，可以自动生成 changelog。我在项目中吃过亏，commit 消息写得乱七八糟，结果回溯 bug 时根本找不到是哪次改动引入的。
3.2.3 push & pull：和远程仓库打交道
git push origin feature/lane_detection_v2
git pull origin developpush 之前，我强烈建议你先 git pull --rebase。为什么？
你想想看，如果直接 pull，会产生一个 merge commit，把历史搞得乱七八糟。用 rebase 的话，你的提交会「嫁接」到远程最新代码之上，历史是一条直线，清爽很多。
注意： 千万不要在公共分支（比如 develop、main）上执行 rebase！rebase 会改写历史，别人如果已经基于你的提交做了开发，那就乱套了。我曾经见过一个同事在 main 上 rebase，结果整个团队花了半天时间才把代码恢复回来。
3.2.4 branch & merge：分支管理与合并
# 创建并切换到新分支
git checkout -b feature/lane_detection_v2
# 切回 develop 并合并
git checkout develop
git merge feature/lane_detection_v2合并时，我推荐用 --no-ff 参数：
git merge --no-ff feature/lane_detection_v2这个参数会强制创建一个 merge commit，哪怕可以 fast-forward。好处是：你能清楚地看到「哦，这里合入了一个 feature 分支」，方便以后回溯。
在 ADAS 项目中，我们经常遇到合并冲突。比如两个人同时改了同一个传感器的配置文件。这时候别慌，用 git mergetool 或者手动解决都行。我的经验是：先沟通，再合并。跟同事确认一下各自改了什么，比闷头解决冲突要快得多。
3.3 .gitignore 配置：别把垃圾文件带进仓库
这个文件太重要了。在 ADAS 项目里，我们经常会有编译生成的中间文件、传感器数据缓存、IDE 配置文件等等。这些东西如果进了版本库，不仅占空间，还会污染代码历史。
一个典型的 ADAS 项目 .gitignore 长这样：
# 编译产物
build/
*.o
*.a
*.so
# IDE 配置
.vscode/
.idea/
*.swp
# 传感器数据缓存
*.bag
*.pcd
*.csv
# Python 虚拟环境
venv/
__pycache__/
*.pyc
# 日志文件
*.log
# 系统文件
.DS_Store
Thumbs.db核心原则： 只提交源代码和必要的配置文件。任何能通过编译或脚本生成的东西，都不要进版本库。
我曾经遇到过一件事：有个同事把整个 build/ 目录都提交了，结果仓库体积瞬间膨胀到 2GB。后来我们花了半天时间用 git filter-branch 才把它清理掉。嗯，从那以后，我每次新建项目第一件事就是配好 .gitignore。
另外，如果你发现某个文件已经被跟踪了，但你想忽略它，记得先把它从 Git 的跟踪列表中移除：
git rm --cached build/some_file.o
echo "build/some_file.o" >> .gitignore这样既保留了本地文件，又不会再被 Git 跟踪。
3.4 实战建议：ADAS 项目中的 Git 最佳实践
最后，给你几个我在实际项目中总结出来的建议：
| 场景 | 建议做法 | 原因 |
|---|---|---|
| 提交频率 | 每完成一个逻辑单元就 commit | 方便回溯和 cherry-pick |
| 分支命名 | feature/模块名_功能描述 | 一目了然，方便查找 |
| 合并策略 | 使用 merge --no-ff | 保留分支历史 |
| 冲突处理 | 先沟通，再手动解决 | 避免误改他人代码 |
| 代码审查 | 合入前必须经过 PR/MR | 保证代码质量 |
好了，Git 核心操作就这些。说白了，命令就那么几个，关键是养成好习惯。下一节咱们聊聊持续集成，那才是真正让 Git 发挥威力的地方。
我的建议： 今天学完，马上在你的 ADAS 项目里实践一遍。从 clone 开始，到创建分支、修改代码、commit、push，再到合并。走完一个完整的流程，比看十遍教程都管用。
公众号:蓝海资料掘金营，微信deep3321