圣狗子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++项目里都有一堆编译产物，比如build目录、*.o文件、可执行文件。这些文件完全没必要提交到git仓库里——它们体积大、改动频繁，而且每个人本机编译出来的都不一样，提交上去只会制造冲突和噪音。
这时候就需要.gitignore文件登场。在仓库根目录下创建一个.gitignore，把不需要追踪的文件和目录列出来：
txt复制build/
*.o
*.a
*.so
*.elf
*.bin
*.log
.vscode/
这个文件本身要提交到git，这样团队里每个人都共享同一套忽略规则。
但这里有个新手常问的问题：如果文件已经被git追踪了，再添加.gitignore还有效吗？答案是无效。git对已经被跟踪的文件是不会理会.gitignore的。你需要先把它们从git的追踪列表里移除：
bash复制git rm -r --cached build/
注意这里加了--cached参数，意思是只从git索引里删除，不动你磁盘上的实际文件。这样处理后，再配合.gitignore，build目录就不会再被追踪了。
至于分支管理，很多单人开发或小型项目其实用不了太复杂的分支策略，master/main一个主分支，feature分支用来开发新功能，开发完合并回主分支，就够了。
bash复制# 创建并切换到新分支
git checkout -b feature/add-camera-support
# 开发完之后切回主分支
git checkout main
# 合并feature分支
git merge feature/add-camera-support
merge和rebase的区别也是老生常谈的问题。我的建议是：在你自己开发的分支上，用rebase让提交历史变得线性干净；在多人协作共享的分支上，老老实实用merge，不要用rebase去改写别人的提交历史。这算是一条黄金法则，遵守它，基本不会在团队协作里出大乱子。
3. 日常高频git操作：从提交规范到解决冲突的完整链路
这一章我按照实际开发中遇到的频率来排，把最常用、但最容易出问题的几个场景逐个拆开讲。
3.1 远程协作的推拉节奏和免密配置
单人开发还好，只要记住git push和git pull就差不多了。但多人协作时，推拉的节奏如果没有掌握好，很容易出现"你的提交覆盖了我的"这种问题。
一个相对安全的日常流程是：
bash复制# 工作前先拉取远程最新代码
git pull
# 本地开发、提交
git add .
git commit -m "fix: correct SPI clock divider calculation"
# 推送前再拉取一次，有冲突先解决
git pull --rebase
# 推送
git push
这里的pull --rebase蕴含了一个关键逻辑：不是把远程的提交和你本地的提交揉成一个合并节点，而是把你本地的提交"挪"到远程最新提交的后面。这样提交历史是一条直线，干净好读。
但如果每次都要输入账号密码，体验会很差。尤其是项目多了之后，频繁输入密码真的很消磨耐心。配置SSH免密是标准做法：
bash复制# 生成SSH密钥对
ssh-keygen -t ed25519 -C "your_email@example.com"
# 查看公钥内容
cat ~/.ssh/id_ed25519.pub
然后把公钥复制粘贴到git平台（GitHub、GitLab、Gitea等）的SSH keys设置里。配置完成后，clone地址要选SSH格式：
bash复制git clone git@github.com:username/myproject.git
配置一次，永久免密。这里有个细节：如果服务器SSH端口不是默认的22，比如是2222，你需要在~/.ssh/config里配置一下：
txt复制Host my-gitlab
HostName gitlab.example.com
Port 2222
User git
然后clone地址就变成了：
bash复制git clone my-gitlab:username/myproject.git
这个技巧对于自建gitlab又改了端口的场景非常实用，记一下能省不少事。
3.2 分支清理和提交历史的整理
开发时间一长，本地分支会积累很多已经合并过或废弃的。定期清理是个好习惯：
bash复制# 查看所有本地分支
git branch
# 删除已合并的本地分支
git branch -d old-feature-branch
# 强制删除未合并的分支（慎用！）
git branch -D old-feature-branch
还有一种情况是提交信息写错了，或者最后一次提交忘了加某个文件。这时候不需要新建一个commit去"补救"，直接用amend修改上一次提交：
bash复制# 修改上一次提交的信息
git commit --amend -m "fix: new correct message"
# 补充文件到上一次提交
git add forgotten-file.c
git commit --amend --no-edit
但注意，amend会改写提交记录，如果这个提交已经推送到远程并且别人在你之后也做了提交，千万不要amend然后强推，否则会把别人的提交历史搞乱。
3.3 解决冲突的正确姿势
多人改同一个文件，几乎必然要遇到冲突。新手遇到冲突的第一反应往往是慌，觉得代码是不是坏了。其实不是，冲突就是git告诉你"这个地方不确定谁对，你来裁决"。
我举个例子，假设你和同事同时修改了config.c，他把第三行的串口波特率改成了115200，你在第五行加了一个调试日志。git merge的时候，如果这两处修改互不重叠，git会自动合并，不会产生冲突；但如果你们俩改了同一行的内容，git就傻眼了，于是标记为冲突。
冲突文件里会看到这样的标记：
c复制<<<<<<< HEAD
#define UART_BAUDRATE 115200
=======
#define UART_BAUDRATE 9600
>>>>>>> feature/add-debug-log
<<<<<<< HEAD和=======之间是当前分支的版本，=======和>>>>>>>之间是另一个分支的版本。你需要人工判断哪个版本保留，或者融合两者。改完后记得删除这些标记，然后：
bash复制git add config.c
git commit -m "merge: resolve baudrate conflict"
这里我想多说一句：解决冲突的时候，不要只关注冲突标记里显示的那几行，还要想清楚双方改动的"意图"。有时候表面上看只是改了一行的数值，但背后可能是两种完全不同的设计思路在碰撞。只追求"能编译通过"，往往会给后续埋坑。我见过太多次冲突是"编译过了但行为不对"，就是因为解决冲突时没有真正理解对方的改法。
4. gdb调试的底层原理和核心命令体系
说实话，很多人对gdb的认知停留在"gdb ./a.out然后敲bt"这个层面，遇到复杂一点的崩溃场景就抓瞎了。想用好gdb，我建议先花几分钟搞清楚它到底是怎么工作的。
4.1 调试符号和编译选项：为什么你的gdb看不到函数名
gdb之所以能告诉你"程序崩在哪个函数第几行"，靠的是一种叫调试符号的东西。调试符号是一张"行号-地址-变量"的映射表，它不属于程序的正常逻辑，只是描述信息。
要让gdb有足够的信息可用，编译时一定要加-g选项：
bash复制gcc -g -o myapp main.c
如果追求更好的调试体验，建议同时关闭编译器优化：
bash复制gcc -g -O0 -o myapp main.c
-O0的意思是关闭所有优化。为什么要关优化？因为编译器优化后会重新排列指令顺序，甚至内联函数、消除变量，这样你观察到的执行顺序和源码可能完全对不上，调试起来非常痛苦。
这里有个小技巧：如果要在开优化的情况下调试，把-g升级成-g3，可以保留更多宏定义和类型信息：
bash复制gcc -g3 -O2 -o myapp main.c
但说句实话，日常开发调试我还是推荐-O0，等要发布的时候再换成-O2重新编译测试一遍。调试阶段和发布阶段分开编译，是最稳妥的。
4.2 启动gdb的三种方式
根据场景不同，启动gdb有三种常见方式：
第一种，直接调试可执行文件：
bash复制gdb ./myapp
在gdb内部用run命令启动程序。如果程序需要带参数：
bash复制(gdb) run --config /etc/myapp.conf
第二种，附加到正在运行的进程，适合排查线上问题：
bash复制# 先找到进程PID
ps aux | grep myapp
# 附加调试
gdb -p 12345
附加调试用的最多的是"程序卡死，想看一下它到底卡在哪个函数"的场景。但注意，附加到进程后，程序默认是暂停的，你需要用continue让它继续跑。
第三种，调试崩溃时生成的coredump文件。这个非常关键，后面单独用一节详细说。
4.3 核心命令：断点、单步、观察点、堆栈
我把最常用的命令按功能拆开讲，每个给出应用场景。
断点相关：
bash复制# 在函数入口打断点
break main
break camera_frame_handler
# 在指定文件指定行打断点
break main.c:128
# 带条件打断点
break main.c:128 if frame_count > 100
条件断点非常有用。比如程序跑了一万帧才崩溃，你总不能一直按continue按一万次吧。加个条件，让gdb在满足条件时自动停下，效率高一个数量级。
单步执行：
bash复制# 下一步，不进入函数
next
# 下一步，进入函数
step
# 执行完当前函数，返回到调用处
finish
# 继续运行到下一个断点
continue
next和step的区别，新手一开始容易混淆：next是把函数调用当成一个黑盒，执行完直接跳到下一行；step是钻进函数内部逐行执行。想在层层嵌套的调用关系里精确定位，这两个命令要搭配着用。
查看变量和内存：
bash复制# 查看变量值
print frame_count
print buffer
# 监视变量，每次变化都会停下
watch frame_count
# 查看内存内容
x/16bx buffer
watch是调试内存异常修改的神器。比如你怀疑某个全局变量被某个线程改坏了，不知道是谁改的，可以用watch监视它，程序一修改就会触发断点，gdb会告诉你当时执行的代码在哪里。这个命令在排查"诡异崩溃"时能救命。
查看调用堆栈：
bash复制backtrace
bt
程序崩溃后，第一件事就是bt，看当前的调用链。然后可以切换栈帧查看调用者的局部变量：
bash复制frame 2
info locals
这一整套组合拳，基本可以应对绝大多数崩溃问题。
5. 用gdb解决真实问题：从崩溃现场到coredump分析
说了这么多命令，我们来走一遍真实的问题排查流程。这是我在RK3568平台上调试摄像头驱动时遇到的典型崩溃场景，也是我认为最能说明gdb价值的一个案例。
5.1 一次段错误的完整排查链路
程序跑一段时间后，随机崩溃，终端输出：
code复制Segmentation fault (core dumped)
碰运气式的瞎猜是最浪费时间的做法。正确思路是这样的：
第一步，用gdb运行程序，复现崩溃：
bash复制gdb ./myapp
(gdb) run
程序崩溃后，gdb会停在崩溃点，自动显示出错的那一行。接着执行bt查看调用堆栈：
code复制Program received signal SIGSEGV, Segmentation fault.
0x00000000004014a2 in process_frame () at capture.c:342
342 memcpy(dst->data, src->data, src->size);
第二步，观察当前的变量值：
bash复制(gdb) print src
(gdb) print dst
(gdb) print src->size
你会很快发现，src->size是个离谱的数值，比如0xffffffff，说明内存已经被破坏，或者src指针本身已经是野指针。
第三步，查看src指针的来源。用frame切换堆栈帧，一层一层往上找：
bash复制(gdb) frame 1
(gdb) info locals
最终可能发现，src指向了一块已经被释放的内存——这个问题的根因往往在"谁释放了这块内存"上。于是你回过去看git log，查最近改动，找到问题提交，然后git checkout到之前的版本验证，确认问题是从哪次提交引入的。
这一整套链路，就是git和gdb配合的典型场景：gdb负责告诉你程序怎么死的，git负责告诉你代码怎么变成这样的。
5.2 coredump：让同事给你一个"事故现场"
段错误出现时，Linux会生成一个coredump文件，里面保存了程序崩溃瞬间的内存镜像。你可以理解为"事故现场"的全景照片，后续可以慢慢分析，不依赖现场复现。
查看coredump是否开启：
bash复制ulimit -c
如果输出是0，说明coredump被禁用了，需要开启：
bash复制ulimit -c unlimited
但这只是当前shell生效，重启就没了。永久开启需要配置/etc/security/limits.conf和systemd的相关参数。以Linux常见的systemd系统为例：
bash复制# /etc/sysctl.d/50-coredump.conf
kernel.core_pattern=/var/crash/core-%e-%p-%t
这样配置后，程序崩溃时，coredump文件会生成在/var/crash/目录下。然后用gdb分析：
bash复制gdb ./myapp /var/crash/core-myapp-1234-1688888888
进入gdb后，同样用bt查看堆栈，用print查看变量。如果你有编译时的symbol和对应的源码版本，甚至可以精确到崩溃时的源码行。这就是为什么每次发布版本都要记录commit hash的原因——你用git log查看当时的提交，切换过去编译出带调试符号的版本，再配合coredump，能还原出一个非常清晰的崩溃现场。
我强烈建议所有做C/C++开发的人都把coredump这套流程玩熟，它能帮你省下一半以上的线上排查时间。
5.3 多线程调试和嵌入式远程调试的两个场景
多线程程序的调试，gdb本身提供了比较完整的支持：
bash复制# 查看所有线程
info threads
# 切换到指定线程
thread 2
# 在所有线程上执行命令
thread apply all bt
最常见的情况是：程序卡死了，你attach上去，然后thread apply all bt一下，看看每个线程分别卡在哪个函数里。如果好几个线程都在等同一个锁，基本就能判断是死锁了。
另一个经常用到的场景是嵌入式开发中的远程调试。比如程序跑在ARM开发板上，但你想在PC上用gdb调试。这时候需要在开发板上运行一个调试服务器，PC端连接过来。常用的组合有gdbserver和J-Link GDB Server、OpenOCD等。
以gdbserver为例，在开发板上：
bash复制gdbserver :2345 ./myapp
在PC端：
bash复制arm-linux-gnueabihf-gdb ./myapp
(gdb) target remote <开发板IP>:2345
连接成功后，用法和本地调试一模一样。很多人在RK3568这类平台上调试裸机或Linux应用时遇到"could not connect to target"之类的报错，多半是端口没开、调试服务器没启动，或者交叉编译器版本不匹配。排查思路是：先确认开发板的gdbserver或OpenOCD进程是否在跑，再确认PC到开发板的网络连通性，最后看gdb的target remote地址是否写对。
6. 版本管理与调试联动：从提交历史定位回归bug
这一章讲的是git和gdb最巧妙的使用结合点。当你面对"新版本出现，旧版本正常"这类回归bug时，单纯用调试器在迷宫里转圈是低效的，正确姿势是用git把"变化"找出来，再用gdb验证假设。
6.1 git bisect：二分定位引入问题的提交
假设你的项目有500次提交，最近一次提交后演示demo死活不正常。你要找的是"哪一次提交引入了这个bug"，如果一个个版本编译测试，最多要试500次，不现实。
这时git bisect闪亮登场。它的核心思想是二分查找，最多只需要log2(500)约9轮就能定位到问题提交。
操作流程：
bash复制# 启动bisect
git bisect start
# 标记当前版本是坏的
git bisect bad
# 标记一个已知的好的版本（比如两周前）
git bisect good <commit-hash>
git会自动切换到一个中间版本，你编译测试这个版本：
- 如果问题存在，执行git bisect bad
- 如果正常，执行git bisect good
每轮操作后git都会自动切换到下一个中间版本，直到定位出第一个"坏"提交。
bisect结束后：
bash复制git bisect reset
回到你原来的分支状态。现在你知道了问题是从哪个提交引入的，然后git show
6.2 git blame：搞清楚每一行代码的来龙去脉
另一种场景：调试时发现某个变量在某个位置的值不对，你想知道这行代码是谁写的、为什么这么写、最后一次修改是什么时候。
bash复制git blame capture.c
输出的每一行都会带上提交hash、作者、日期和代码内容。看到hash后可以：
bash复制git show <commit-hash>
查看那次提交的完整改动，包括commit message里写的修改理由。有时候你会惊奇地发现，某行看起来莫名其妙的代码，背后藏着一个非常曲折的bug修复故事。理解了这个故事，你调试的时候就不容易破坏原有逻辑。
当然，git blame只能告诉你"最后一次修改"这行的人。如果想知道这行代码的完整演进历史：
bash复制git log -p --follow -L 128,128:capture.c
这条命令会列出第128行的所有历史变更记录，非常强大。
6.3 编译构建和调试要保持一致
最后提醒一个细节：用git配合gdb调试时，一定要保证你正在调试的二进制文件和当前检出的源码版本是匹配的。
我见过这样的场景：同事用git checkout切到了旧的提交去查看历史代码，但忘了重新编译，然后拿着旧的二进制文件去调试，gdb显示的源码行号完全对不上，排查了大半天，最后才发现是版本错位——浪费的时间足够休息一个下午了。
一个稳妥的习惯是：每次git checkout切换分支或提交后，务必重新编译。编译前可以用git status确认工作区是干净的，排除本地未提交改动的影响。如果你必须带着本地改动调试，git stash是一个方案，但记得到调试完及时stash pop回来。
7. 高频报错速查：git和gdb常见问题定位思路
这一节我整理几个高频报错，直接给排查思路。遇到问题先按这个思路走，大概率比自己瞎试更快。
7.1 git相关报错快速排查
报错1：failed to push some refs to
这是推送被拒绝，通常因为远程有本地没有的提交。先git pull --rebase，解决冲突后再推送。如果pull时报"cannot pull with rebase: You have unstaged changes"，说明本地有未提交的改动，先git status看清楚，再决定是commit还是stash。
报错2：Permission denied (publickey)
SSH密钥没配对。检查一下SSH key是否添加到git平台，或者本地是否换了电脑导致密钥丢失。可以用ssh-keygen重新生成再添加。
报错3：Authentication failed
密码或token错误。很多平台的密码认证已经被token取代，如果你用的是账号密码方式，大概率会失败。正确做法是生成一个personal access token，作为密码使用，或者在远程URL里直接带着token。
7.2 gdb相关报错快速排查
报错1：No symbol table is loaded
这个报错说明你编译可执行文件时没有加-g选项。解决办法是重新编译，确保编译命令里有-g。
报错2：Remote connection closed或could not connect to target
嵌入式远程调试时常见的报错。检查顺序：调试服务器（gdbserver、OpenOCD、J-Link GDB Server）是否启动成功、端口是否被占用、开发板和PC之间网络是否互通。
报错3：Missing separate debuginfos
系统库缺少调试符号，不影响基本调试，只是查看系统库函数内部时会受限。可以安装debuginfod相关工具，或者在调试时跳过系统库内部，专注在自己代码的调用逻辑上。
7.3 我的一个实操排查记录
上个月我在调试一个串口程序，现象是收够一定长度的数据就崩溃。用gdb直接跑，崩溃位置指向一段memcpy，src指针飘忽不定。我用watch监视了src指向的缓冲区起始地址，发现协议解析函数在某个分支里提前释放了buffer，而处理流程没有同步更新指针状态。通过git blame查到这行代码是三个月前为了修内存泄漏加的，那个修复引入了新的use-after-free问题，最近的改动放大了它。
整个过程从开始到定位，用了不到半天。如果没有git历史作为参照，可能会在"到底是哪里改了内存"上浪费更多时间。这就是我说的联动价值：调试器看到的是"坏掉的那一刻"，版本管理看到的是"逐渐变坏的过程"，两者缺一不可。
8. 一些实战习惯：开发和调试阶段一定要坚持的小事
说完了工具和命令，最后再分享几个我自己坚持了很久的习惯，这些看起来不起眼，但在关键时候能省下成倍的时间。
第一个，提交前做一次git diff review。很多人习惯git add .然后直接commit，跳过review。但这个习惯特别容易把调试用的临时日志、测试代码、甚至写错的注释一起提交进去。每次commit前养成git diff的习惯，用一分钟扫一遍改动，能挡住大量低级错误。
第二个，提交信息里写清楚"为什么"。我在前面讲过的type格式是一个骨架，但骨架之外，正文部分最好再写两句背景。比如：
code复制fix: correct frame buffer overflow
The issue was caused by incorrect calculation of buffer size
when resolution changed from 1080p to 4K. Added boundary check
and updated the size calculation logic.
两个月后你回来看，仍然能快速理解这次修改的上下文。
第三个，调试时的辅助代码不要顺手提交。比如你为了定位问题加了一堆printf或者fprintf(stderr, ...)，问题解决后记得清理。如果确实需要保留日志，也请用专门的日志模块，而不是随手printf。否则这些临时代码积少成多，最后代码库变得非常臃肿，还会影响性能。
第四个，也是我认为最重要的一个习惯：遇到崩溃，先开gdb，不要直接猜。很多人在程序崩了之后第一反应是"加个print试试"，运气好能蒙对，运气不好就是浪费时间。正确路径是gdb跑起来，bt看堆栈，print看关键变量。即使是复现不了的问题，coredump也能帮你保存现场。学会用工具代替瞎猜，是一个程序员从新手走向熟练的分水岭。
根据我个人的经验，git和gdb不是两个孤立学习的工具，它们应该在一次次真实的debug过程里被逐渐熟练起来。你可以从今天开始，在下一个项目里强制自己用git管理每一处改动，遇到问题第一时间打开gdb。坚持三个月，你会发现自己解决bug的速度和当初相比完全不在一个量级上。