提交的最佳实践：在嵌入式/芯片开发中构建高效的Git工作流
上周调试一块新板子，半夜两点还在跟寄存器死磕。问题出在某个外设驱动上，明明上周还能正常初始化，这周突然就卡死了。翻遍最近提交记录，发现某次提交的注释只写了“fix bug”三个字，改了七八个文件。那一刻真想穿越回去掐死自己——这哪是修复问题，分明是埋雷。
嵌入式开发跟纯软件不太一样，我们打交道的是硬件、是时序、是物理世界的电信号。Git在这里不只是版本管理工具，更是调试的时光机、团队的协作协议、质量的守门员。
提交粒度：一次只做一件事
见过那种“周二大提交”吗？一个人攒了一周代码，周五下班前全推上去，注释写“本周工作”。这种提交在嵌入式项目里就是灾难。
芯片底层驱动改两行，中间层适配改三处，应用示例再调一下——看起来相关，其实该拆成三次提交。为什么？因为回滚的时候你可能只想退到驱动修改前的状态，而不是把整个功能都倒回去。
// 反面教材：一次提交混改多个模块// 提交信息："优化SPI性能和修复ADC采样错误"// 改了spi_driver.c、adc_driver.c、hal_config.h、demo_app.c// 正面做法：拆开提交
