如果你在 Windows 上做开发/写文档/做配置，最常见的痛点不是“不会写代码”，而是：不会把改动安全地记录下来、不会和别人协作、遇到冲突就慌。GitHub Desktop 把版本控制里最容易出错的部分（远端、分支、提交历史）做成了可视化流程；VS Code 则负责编辑与少量 Git 操作，两者配合非常适合新手建立稳定习惯。
本文目标：让你从 0 到 1 跑通一条可复用的工作流——克隆仓库、建立分支、提交、同步、提 PR、合并与回退，并知道常见异常怎么处理。
1）安装 GitHub Desktop：在官网下载安装即可。安装完成后首次打开，使用你的 GitHub 账号登录。
2）安装 VS Code：建议安装稳定版，并启用自动更新。你可以在 VS Code 里安装一些常用扩展（按需）：中文语言包、GitLens、EditorConfig。
3）配置工作目录：建议在磁盘上新建一个专门的文件夹作为所有项目的根目录，比如 D:Projects，避免散落在桌面或系统盘。
在 GitHub Desktop 里点击 File → Clone repository，选择你要克隆的仓库（或输入 URL）。克隆路径选择到你的项目根目录。
克隆完成后，点击 Open in Visual Studio Code（或从菜单打开）。此时你已经完成了“本地工作区”和“远端仓库”的连接。
小检查：在 GitHub Desktop 的上方确认当前分支是 main 或 master，右侧没有未同步提示。
推荐规则：任何非紧急改动都在新分支里完成。这样你随时可以撤销、对比、做 PR 审查。
在 GitHub Desktop 点击分支下拉，选择 New Branch。分支命名建议简洁明确：
feat/add-readme fix/typo chore/update-config创建后会提示是否发布（Publish branch）。如果你打算做 PR 或与同事协作，建议立刻发布。
在 VS Code 中正常编辑文件。完成一个“可描述、可回滚”的小改动后，就进行一次提交。
提交的核心是写好提交信息（Commit message）。你可以用一条简单模板：
类型: 做了什么（尽量 1 行说清） 可选：为什么这么改/影响范围/注意事项在 GitHub Desktop 的左侧会看到变更列表，勾选本次要提交的文件，在 Summary 里写标题，De ion 里写补充说明，然后点击 Commit to <branch>。
建议节奏：小步快跑。不要憋到“改了一大堆”才提交，后续排错会非常痛苦。
当你提交后，点击 Push origin 将本地提交推送到远端。协作时要养成“先拉取后提交”的习惯：
开始工作前：Pull（把远端最新改动拉下来） 完成一个阶段：Commit 准备协作/备份：Push如果远端有新提交，你会看到 Pull 的提示。先 Pull 再继续改，冲突会更少。
当你的分支改动完成后，在 GitHub Desktop 点击 Create Pull Request。浏览器会打开 GitHub 的 PR 页面：
PR 标题：一句话说明做了什么；PR 描述：补充背景、改动点、验证方式（比如“已在本地跑通/已检查截图”）。
如果是团队协作，建议勾选 reviewer 或指定负责人；如果是个人项目，也建议保持 PR 习惯，后续回溯会更清晰。
1）改错了文件怎么撤回？ 在 GitHub Desktop 的 Changes 列表里可以右键文件，选择丢弃改动（Discard changes）。建议只对你确认不需要的改动执行。
2）提交信息写错了？ 最稳妥做法是再提交一次修正（例如补充说明）。如果你还没 Push，某些情况下也可以在本地修正提交信息，但新手建议优先用“再提交一次”的方式，风险更低。
3）出现冲突（Conflict）怎么办？ 先确认冲突文件，理解两边差异。用 VS Code 的冲突解决界面逐块选择“保留你的/保留对方的/都保留”，解决后再提交一次“解决冲突”的提交。
4）换电脑如何继续？ 只要远端仓库在，你在新电脑上安装 GitHub Desktop，登录后重新 Clone 即可；分支与历史会同步回来。
1）建立 .gitignore：把临时文件、缓存、构建产物排除掉，仓库更干净。
2）每次提交都尽量可描述：未来你回头看提交历史，会感谢现在的自己。
3）把“发布分支/提 PR”当作备份：重要改动及时 Push，避免本地电脑故障造成损失。
到这里，你已经拥有了一套在 Windows 上可长期使用的协作流程：分支隔离改动、提交记录进度、同步保障安全、PR 保证可审查与可回退。后续你可以在这个基础上逐步引入更专业的规范（如 Conventional Commits、自动化检查、CI），但第一步永远是把这条主流程跑顺。
