理解工作流程：Issue、Branch与Commit规范

理解工作流程：Issue、Branch与Commit规范

上周帮同事排查一个嵌入式驱动问题，发现他直接从主分支拉了个fix分支改代码，提交信息写的是“改了点东西”。三个月后另一个模块报错，我们翻遍提交历史也定位不到那次改动的原因。这件事让我意识到，很多工程师把Git用成了“高级文件备份工具”，却忽略了它背后的一整套协作语言。今天我们就聊聊开源项目里那些看似繁琐、实则能救命的流程规范。

从Issue开始：别急着写代码

新手最容易犯的错误就是看到问题直接动手改。去年给Linux内核提交一个GPIO驱动补丁时，我自测完美，结果维护者第一个问题就是：“对应的Issue编号呢？” 当时就懵了。

现在我的习惯是，哪怕再小的修改，也先去看看项目的Issue列表。几个动作不能省：

• 搜索是否有类似问题被讨论过（我常用is:issue is:open搜关键字）
• 如果没找到，用模板新建Issue，把复现步骤、硬件型号、内核版本写清楚
• 等维护者确认这是真问题，并且没人正在修复，再开始写代码

有些大型项目比如TensorFlow，甚至要求每个PR都必须关联一个Issue。为什么这么麻烦？因为维护者需要知道你这行代码是为了解决什么具体问题，三周后他review几十个PR时，还能记得上下文。

分支命名：你的工程名片

早期我习惯用dev、test这种分支名，在