圣狗子1. 从一次日常开发说起：git和gdb到底解决什么问题
入行这些年，我被问得最多的两个问题，一个是"代码怎么管"，另一个是"程序崩了怎么查"。前者指向git代码托管，后者指向gdb调试。有意思的是，很多刚接触嵌入式或者Linux下C/C++开发的朋友，往往把这两件事割裂开来看——觉得git就是提交代码用的，gdb就是看堆栈的，两者井水不犯河水。
但实际上，在一个真实的项目开发闭环里，git和gdb是紧密咬合的两个齿轮。举个我自己的例子：接手一个基于RK3568的摄像头采集项目，同事前一天提交了一个改动，第二天测试反馈画面偶尔卡死。我第一反应不是直接打开源码瞎看，而是先git log看看最近提交了什么，git diff对比一下改动点，缩小嫌疑范围。等定位到可能是某个数据结构在多线程下访问越界，再用gdb挂上调试，复现崩溃现场，拿到调用堆栈，才最终确认根因。
这一套流程走下来，你会发现git不只是个"代码备份工具"，gdb也不只是"打日志的替代品"。git帮你回答"代码从哪开始变坏的"，gdb帮你回答"程序到底死在哪个函数哪一行"。两者配合，才是真正的调试效率利器。
这篇文章不打算写成一本工具书，而是把我在实际项目里用git和gdb的经验串一遍，包含最常用的命令、最容易踩的坑、以及怎么把两件事联动起来解决实际问题。无论你是刚接触Linux开发的在校生，还是已经写了两三年业务代码但没系统搞过调试的工程师，这篇文章应该都能给你一些参考。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. git代码托管：先搞懂配置和本地仓库的底层逻辑
很多新手用git，第一步就卡在概念上——工作区、暂存区、本地仓库、远程仓库，这四个词背得滚瓜烂熟，但实际操作起来还是懵。其实没那么玄乎，你可以把git想象成一个带"后悔药"的存档系统：工作区是你正在改的文件，暂存区是"准备要存档"的清单，本地仓库是已经存好的存档点，远程仓库则是存在服务器上的备份盘。
2.1 安装和初始化：别忽略user.name和user.email
git的安装本身没什么难度，Windows下下载安装包一路Next，Linux下一条命令搞定：
bash复制# Ubuntu/Debian系
sudo apt install git
# CentOS/RHEL系
sudo yum install git
装完之后第一件事，配置用户名和邮箱。这个很多人会忽略，但等你commit完才发现提交记录里显示的是"unknown"或者别人的名字，再回去改就非常麻烦。配置方法：
bash复制git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"
建议把这两条配置成全局的，因为绝大多数情况下，你所有项目的提交人都是你自己。用--global配置后，会写入到~/.gitconfig文件里，以后每个仓库默认沿用这个身份。
这里顺便提一个容易踩的坑：如果你在某个公司的项目里用个人邮箱提交了代码，然后这个项目是公开的，你的邮箱就会被爬虫抓走，然后收到一堆垃圾邮件。所以现在很多公司都要求用公司邮箱，或者开启git平台的邮箱隐藏功能。个人项目的提交邮箱，建议也斟酌一下再用。
初始化一个仓库有两种方式。一种是从零开始：
bash复制mkdir myproject && cd myproject
git init
另一种是从远程克隆：
bash复制git clone https://github.com/username/myproject.git
这两者的区别在于，git init是在本地凭空创建一个仓库，git clone是把远程已有的仓库连同所有历史记录拉下来。新手最容易搞混的是：在克隆下来的仓库里，远程仓库origin已经自动帮你配置好了，直接git push就能推上去；但在git init的仓库里，你需要手动添加远程地址：
bash复制git remote add origin https://github.com/username/myproject.git
2.2 三棵树的概念和日常提交节奏
git的工作区、暂存区、本地仓库这三者，用一句话概括就是：你在工作区改文件，用git add把改动放进暂存区，再用git commit把暂存区的内容打包成一次永久记录。
日常开发里最常见的节奏是这样：
bash复制# 查看当前状态，看看哪些文件被改了
git status
# 把改动加入暂存区
git add .
# 提交到本地仓库
git commit -m "feat: add camera frame capture module"
很多新手会问，为什么不能一步到位直接git commit，非要中间加一个git add？因为git add给了你一次"挑选"的机会。比如你同时改了两个逻辑无关的文件，一个修复了A功能，一个优化了B功能，你完全可以分开add、分开commit，这样提交历史就非常清晰，以后回溯到某个功能时一目了然。
这里我还要特别强调一下提交信息（commit message）的规范。不要写什么"update""fix bug"这种毫无信息量的话。我见过最离谱的commit message是连着十几个"update"，等三个月后回来看，根本不知道那次改动是干什么的。
一个比较通用且好用的提交格式是：
code复制<type>: <subject>
其中type包括：
- feat: 新功能
- fix: 修复bug
- docs: 文档改动
- style: 代码格式调整（不影响功能）
- refactor: 重构（不新增功能也不修bug）
- perf: 性能优化
- test: 测试相关
- chore: 构建或辅助工具改动
举个例子：
code复制fix: resolve frame buffer overflow in multi-thread capture
这样写的好处是，以后git log看历史，一眼扫过去就知道每次提交的类型和目的。配合git log --oneline，整个项目的演进脉络清清楚楚。
2.3 .gitignore和分支管理：保护该保护的，隔离该隔离的
很多C/C++项目里都有一堆