1. 为什么不能"只靠拖动"?(避坑指南)
-
版本覆盖风险 :如果你和同事都在改同一个文件。你拖动过去覆盖了板子上的文件,而同事恰好也刚改完一段代码。你的拖动会直接抹掉同事的心血,且没有任何记录可以找回。
-
代码不同步:你的 Windows 本地有一套代码,板子上有一套,同事电脑里还有一套。时间一长,你根本不记得哪一边的代码才是"最新且正确"的。
-
换行符污染 :Windows 默认
CRLF,Linux 默认LF。频繁手动拖动容易导致 Makefile 或 Shell 脚本在板子上报错(因为多了不可见的\r字符)。
2. 冯博士(Feng Xu)推荐的"双轨制"工作流
在博客中,你可以这样向读者推荐:
🟢 场景 A:快速验证(用"拖动")
-
适用情况 :你刚写了一个
printf想看看输出,或者改了一个小的if逻辑。 -
操作 :直接拖入 VS Code,下方终端
make -j8运行。 -
优点:零等待,反馈极快。
🔵 场景 B:团队协作/功能交付(用"Git")
-
适用情况 :你完成了一个完整的
spi_oled模块,或者要同步同事的进度。 -
操作:
-
Windows 本地 :
git commit+git push到 Gitee/GitLab。 -
板子 SSH 终端 :执行
git pull。
-
-
优点:
-
自动合并:Git 会智能对比你和同事的代码,不会发生覆盖。
-
后悔药 :改错了随时可以
git checkout回滚。
-
3. 进阶神技:在 VS Code 里直接改板子的代码
其实,既然你已经 SSH 连接成功了,你甚至连"本地 Windows 代码"都不用打开。
-
操作 :直接在 VS Code 那个 SSH 远程窗口里编辑文件。
-
效果 :你改的每一行代码,实时就保存在板子的硬盘上。
-
博客亮点 :这就是所谓的"原生开发 "。你不需要在 Windows 存一份,板子存一份。你只需要在板子上改完,直接在板子上
git commit提交,全世界(包括你 Windows 本地)就都同步了。
✍️ 总结你的博客结尾建议:
Feng Xu 的开发铁律:
小改动:直接在 VS Code 远程窗口里改,存盘即生效。
大功能 :本地 Windows 写完,拖动过去跑通。
交作业 :全员通过 Git 汇总到服务器,拒绝"文件传口令"。
🚀 现在的最后一步挑战:
既然文件已经就位,我们要不要试着在 VS Code 的终端里跑一下编译?
-
按
Ctrl + `打开终端。 -
输入
ls确认看到makefile。 -
输入以下命令并截图看看结果:
Bash
make clean && make -j8