GitHub：远程同步与协作
本地 Git 负责历史，远程仓库负责备份、协作与部署来源。push 和 pull 只是同步已存在的提交。
- 代码离开本机后仍有可信版本来源。
- 本地仓库、远程仓库、分支和 origin
- 创建远程仓库，推送两次提交，并在网页上确认提交历史。
- 完成 3.3「Git：给代码设置可解释的存档点」
FOUNDATION
必须理解
本地 Git 负责历史，远程仓库负责备份、协作与部署来源。push 和 pull 只是同步已存在的提交。
GitHub 托管远程 Git 仓库，为代码提供异地副本、协作入口和部署来源。Git 负责版本历史，GitHub 是围绕这些历史提供服务的平台，两者不是同一个东西。
本地 Git 像你电脑里的原稿与修订记录，GitHub 像受控的云端资料室。push 是把已有存档送上去，pull 是把远端新存档同步回来。
任务应用的本地提交推送到 GitHub 后，部署平台可以读取指定分支构建；另一台电脑也能 clone 出完整历史。
本地仓库、远程仓库、分支和 origin
你的电脑和 GitHub 上各有一份仓库历史，它们不会凭空同步。origin 只是大家常用的远程名字，真正决定推到哪里的是后面的 URL。
基础概念
本地仓库保存在自己的电脑，远程仓库位于 GitHub 等服务；分支是指向一串提交当前位置的名称，`origin` 只是 Git 为远程地址常用的别名。
进一步理解
创建本地提交不会自动上传。`git remote -v` 显示远程名称与地址，当前分支决定默认推送哪条历史。远端也可能已有本地没有的提交。
把远程称为 origin 是习惯而非规则，一个项目可以有多个远程。分支不是完整复制文件夹，而是通过提交关系表示不同开发路线。
任务应用在本地 `main` 上有三次提交，配置 GitHub 地址为 origin 后推送，远端才拥有同样历史。
GitHub 不是 Git 本身。离线时本地 Git 仍能提交；删除远端也不等于本地历史立刻消失。
这一小节记住：先分清历史在哪、当前分支指向哪、远程名称连接到哪。
SSH 公钥与私钥的安全边界
分支可以理解成指向一串提交的标签。push 把本地新提交送上去，pull 把远端变化拿回来并尝试合并；同步前先看看两边各自有什么。
基础概念
push 把本地已有提交发送到远端，fetch 只获取远端信息，pull 通常相当于获取后再合并或变基；merge 把不同提交路线汇合。
进一步理解
同步冲突不是 Git 损坏，而是两边修改了 Git 无法自动决定的同一区域。解决时要理解双方意图，不能随机保留一边。
推送前查看状态、分支和日志；拉取前保存当前工作。若远端领先，先理解差异再选择合并方式。
同伴修改任务卡样式、你修改同一段布局时，pull 可能产生冲突；应比较两种需求，整理出同时满足的新版本再提交。
pull 不等于下载完整备份，push 也不会上传未提交文件。它们同步的是提交历史。
这一小节记住：同步操作传递提交；冲突要依据内容意图解决。
提交、推送、拉取和合并的标准节奏
连接 GitHub 可以走 HTTPS，也可以走 SSH。SSH 公钥可以放到平台上，私钥只能留在自己的设备里；.env 和数据库备份更不该进公开仓库。
基础概念
HTTPS 与 SSH 是连接远程仓库的两种常见方式。SSH 使用公钥确认设备，私钥证明身份；敏感配置和数据仍需由仓库规则单独保护。
进一步理解
公钥设计为可以分享，私钥应只保存在受保护设备。HTTPS 通常使用短期凭证或令牌，也不能写入远程 URL 或源码。
仓库可见性不是秘密管理方案。即使私有仓库也应避免提交密钥、生产数据和个人信息，因为成员、日志或后续公开都可能扩大暴露。
把 SSH 公钥添加到 GitHub 后用私钥完成认证，但 `.env` 保留在本地安全存储，只提交字段名称示例。
SSH 私钥与登录密码作用相近，绝不能因“公钥能上传”而把两者混淆；公钥可分发不意味着整个密钥对都能公开。
这一小节记住：连接凭证只证明你是谁，不会自动过滤仓库里的敏感内容。
AI COLLABORATION
AI 如何参与
让 AI 根据 git status、branch、remote 和 log 判断同步状态，不要凭感觉重复 push。
推荐协作顺序
- 1
把当前分支、最近提交和 remote -v 的脱敏结果给 AI。
- 2
让它说明本地与远端将发生什么，再给第一次 push 命令。
- 3
推送后在 GitHub 页面核对提交，而不是只相信终端最后一行。
我已经有一个含两次提交的本地 Git 仓库，想第一次推送到 GitHub。请按“检查当前状态—确认远程地址—确认分支—推送—网页验证”给步骤。每一步说明预期输出；遇到认证失败时只给安全排查，不要求我粘贴令牌或私钥。
一套先检查再连接的同步步骤，清楚区分本地提交、远程仓库、分支和认证。
人工检查清单
- 确认远程 URL 指向自己的目标仓库，公开可见性符合预期，提交历史中没有秘密。
- 让 AI 先读取本地分支、远程地址和双方提交关系，再建议同步命令。
- 同步后同时核对本地日志和 GitHub 页面，确认目标提交真实存在且没有秘密文件。
COMMON TRAPS
常见误区
错误不是需要隐藏的失败，而是帮助你看清系统边界的证据。下面三类问题在 AI 辅助学习中最常出现。
把 GitHub 当网盘
- 你会看到
- 直接在网页零散上传文件，本地历史和远端历史互相对不上。
- 为什么发生
- 网页上传绕过了本地提交节奏，文件与历史容易分离，也无法清楚比较一次变更的意图。
- 怎样纠正
- 先在本地形成提交，再通过 push 同步完整历史。
远程地址指错仓库
- 你会看到
- 命令成功执行，代码却出现在另一个项目或账户下。
- 为什么发生
- 不了解双方提交关系就反复 push 或 pull，会不断制造拒绝与冲突，甚至覆盖正确方向。
- 怎样纠正
- 推送前查看 remote -v，并在浏览器确认仓库名称与可见性。
认证失败就粘贴凭证
- 你会看到
- 把令牌或私钥内容发进聊天，希望 AI 帮你找格式问题。
- 为什么发生
- 私有仓库降低公开暴露，却不消除成员误用、凭证泄漏和未来改为公开的风险。
- 怎样纠正
- 只给错误文本和公钥状态；泄露过的凭证应立即撤销和重建。
HANDS-ON
动手任务
创建远程仓库，推送两次提交，并在网页上确认提交历史。
- 完成 3.3「Git：给代码设置可解释的存档点」
跟着做
- 01
在 GitHub 创建空仓库，不在线生成重复 README。
- 02
在本地查看当前分支和最近提交。
- 03
添加远程地址并用 remote -v 复核。
- 04
推送当前分支，并在网页确认两次提交。
- 05
做一次小文案修改、提交并再次推送，观察新增历史。
代码离开本机后仍有可信版本来源。
在另一目录 clone 仓库，确认文件与提交历史都能恢复，再删除练习副本时只处理明确文件。
离开本课前，自问四件事
- 本地仓库、GitHub 远程、分支和 origin 分别是什么？
- push、fetch、pull 和 merge 各自移动或改变什么？
- 发生冲突时为什么不能随便选择“保留我的”或“保留对方的”？
- SSH 公钥、私钥和项目秘密应分别存放在哪里？
确认完成后，会同步更新学习中心的课程学习进度。