3、Git工作流：Fork仓库、创建分支、提交PR、Code Review流程、Squash提交

好，咱们进入第三章。这一章聊的是Git工作流，说白了就是你怎么跟NuttX社区打交道。我见过太多新手，代码写得不错，结果PR提交得乱七八糟，被维护者打回来重做。嗯，咱们今天就把这事捋清楚。

3.1 为什么要用Fork工作流？

NuttX的主仓库在apache/nuttx上。你直接往那上面推代码？不行，你没权限。社区的做法是：你先Fork一份到自己名下，改好了再通过PR（Pull Request）把代码送回去。

我个人习惯把Fork叫做「我的私人副本」。你在GitHub上点一下Fork按钮，就会在你自己账号下生成一个仓库，比如你的名字/nuttx。这个仓库跟主仓库是独立的，你想怎么改都行。

3.2 创建分支：别在main上干活

很多人Fork完仓库，直接就在main分支上改代码。这是个大坑。为什么？因为main分支应该保持跟上游同步，你改了之后，下次想同步上游就麻烦了。

我建议你这样做：

# 先克隆你的Fork
git clone git@github.com:你的名字/nuttx.git
cd nuttx

# 添加上游仓库
git remote add upstream https://github.com/apache/nuttx.git

# 创建功能分支
git checkout -b fix-spi-bug

分支命名也有讲究。我个人习惯用「类型/简短描述」的格式：

• fix/spi-driver-crash — 修bug
• feat/add-i2c-support — 加新功能
• doc/update-readme — 改文档

这样维护者一看分支名，就知道你要干嘛。

3.3 提交PR：别一股脑全推上去

代码改完了，提交PR。这里有个关键点：PR要小。我在项目中遇到过有人一个PR改了50个文件，涉及3个不同的功能。结果呢？维护者看了两周还没看完，最后要求拆开。

一个PR只做一件事。这是铁律。

提交PR的步骤：

1. 确保你的分支是基于最新的上游main
2. 运行本地测试，确保不破坏现有功能
3. 提交PR时，写清楚「做了什么」和「为什么做」

3.4 Code Review流程：别怕被怼

PR提交后，维护者会来Review。说白了就是挑毛病。我第一次给NuttX提PR时，被要求改了4次。当时心里挺不爽的，后来发现人家是对的。

Review时维护者会关注这些：

检查项	常见问题
代码风格	缩进不对、命名不规范
逻辑正确性	边界条件没处理、内存泄漏
兼容性	破坏了其他架构的编译
文档	新功能没写注释或文档

收到Review意见后，别急着反驳。先想想人家说的有没有道理。如果确实有问题，就在本地改，然后重新推送。GitHub会自动更新PR。

3.5 Squash提交：让历史干净一点

你改一个bug，可能提交了5次：第一次写代码，第二次修拼写错误，第三次加注释……这些提交记录对别人来说毫无意义。维护者希望看到的是：一个功能，一个提交。

这时候就需要Squash（压缩提交）。

操作很简单：

# 查看最近的提交
git log --oneline

# 压缩最近3个提交
git rebase -i HEAD~3

在打开的编辑器里，把后面的提交前面的pick改成squash（或简写s）。保存退出后，会让你写一个新的提交信息。

嗯，这里要注意：不要Squash已经推送到远程的分支，除非你确定没人基于你的分支开发。如果已经推送了，需要用git push --force强制推送。

3.6 避坑指南

我曾经犯过一个低级错误：在Fork的仓库里直接改了main分支，然后提交PR。结果上游更新了，我这边合并冲突一大堆。后来学乖了，永远在功能分支上开发。

还有一次，我忘了添加upstream远程仓库，结果同步上游时搞了半天。你想想看，如果连上游都不同步，你的代码可能跟主线差了好几个版本，合并起来痛苦死。

最后说一句：Git工作流这东西，光看没用。你得动手练。找个简单的bug修一下，走一遍完整的流程：Fork → 分支 → 修改 → PR → Review → Squash → 合并。走完一遍，你就懂了。