GitHub：远程同步与协作
GitHub 保存远程仓库并支持协作。本地提交仍由 Git 产生，push 只是把已有提交同步到远端。
- 把两次本地提交推送到远程，并能从分支、远程地址和日志说明同步状态。
- 本地仓库、远程仓库、分支和 origin
- 演练GitHub：远程同步与协作后，应当把两次本地提交推送到远程，并能从分支、远程地址和日志说明同步状态，并保留diff、提交记录、远端历史和公开页面作为可重复检查的依据。
- 完成 3.6「Git：给代码设置可解释的存档点」
FOUNDATION
必须理解
GitHub 托管远程 Git 仓库，为代码提供异地副本、协作入口和部署来源。Git 负责版本历史，GitHub 是围绕这些历史提供服务的平台，两者不是同一个东西。
本课依次讲清本地仓库、远程仓库、分支和 origin、SSH 公钥与私钥的安全边界和提交、推送、拉取和合并的标准节奏，最后通过“做一次小文案修改、提交并再次推送，观察新增历史”检查学习结果。
本地 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 如何参与
在GitHub：远程同步与协作这一课，AI 负责根据真实材料解释本地仓库、远程仓库、分支和 origin并指出遗漏，学习者负责控制范围、执行修改和核对diff、提交记录、远端历史和公开页面。
推荐协作顺序
- 1
把当前分支、最近提交和 remote -v 的脱敏结果给 AI。
- 2
让它说明本地与远端将发生什么，再给第一次 push 命令。
- 3
推送后在 GitHub 页面核对提交，而不是只相信终端最后一行。
请根据 git status、git branch、git remote 与 git log 判断本地和远端状态。只给最小同步步骤，每一步说明会改变哪里。禁止索取私钥、令牌和环境变量，禁止使用强制推送。
一套先检查再连接的同步步骤，清楚区分本地提交、远程仓库、分支和认证；GitHub：远程同步与协作的人工验收必须回到真实页面、请求、终端、测试或数据结果，不能用 AI 的文字说明代替。
人工检查清单
- 确认远程 URL 指向自己的目标仓库，公开可见性符合预期，提交历史中没有秘密。
- 让 AI 先读取本地分支、远程地址和双方提交关系，再建议同步命令。
- 同步后同时核对本地日志和 GitHub 页面，确认目标提交真实存在且没有秘密文件。
COMMON TRAPS
常见误区
下面三类问题会让任务看似完成，却经不起刷新、错误输入或真实环境检查。先看现象，再找原因和修正方法。
把 GitHub 当网盘
- 你会看到
- 网页上零散上传文件，历史与本地脱节
- 为什么发生
- 绕过本地提交会造成两边历史不一致，也失去可说明的改动记录。
- 怎样纠正
- 在本地形成提交后再同步
共享私钥或访问令牌
- 你会看到
- 凭证进入聊天、代码或截图
- 为什么发生
- 拿到凭证的人可以按其权限访问仓库，删除聊天消息并不能使凭证失效。
- 怎样纠正
- 只共享脱敏错误，凭证始终留在本地
不看分支反复推送
- 你会看到
- 提交被送到错误分支或被拒绝
- 为什么发生
- push 会把当前提交发送到指定上游，分支和上游不符时结果自然不对。
- 怎样纠正
- 推送前核对当前分支、上游和日志
HANDS-ON
动手任务
把两次本地提交推送到远程，并能从分支、远程地址和日志说明同步状态。
- 完成 3.6「Git：给代码设置可解释的存档点」
跟着做
- 01
在 GitHub 创建空仓库，不在线生成重复 README。
- 02
在本地查看当前分支和最近提交。
- 03
添加远程地址并用 remote -v 复核。
- 04
推送当前分支，并在网页确认两次提交。
- 05
做一次小文案修改、提交并再次推送，观察新增历史。
把两次本地提交推送到远程，并能从分支、远程地址和日志说明同步状态。
在另一目录 clone 仓库，确认文件与提交历史都能恢复，再删除练习副本时只处理明确文件。
离开本课前，自问四件事
- 本地仓库、GitHub 远程、分支和 origin 分别是什么？
- push、fetch、pull 和 merge 各自移动或改变什么？
- 发生冲突时为什么不能随便选择“保留我的”或“保留对方的”？
- SSH 公钥、私钥和项目秘密应分别存放在哪里？
确认完成后，会同步更新学习中心的课程学习进度。