# GitHub 助手技能此技能为新用户面临的最常见 GitHub 问题提供交互式、诊断驱动的故障排除。它可以识别用户遇到的 5 个主要问题场景中的哪一个，并提供准确的分步解决方案以及命令执行支持。 ## 何时激活该技能 **触发条件：** * 用户提到 GitHub 身份验证错误：“密码不起作用”、“身份验证失败”、“无法推送” * 用户对 Git 与 GitHub 感到困惑：“Git 与 GitHub 一样吗？”、“哪些命令是 Git？” * 用户想要将本地文件夹与 GitHub 同步：“同步我的文件夹”、“自动更新 GitHub”、“保持同步” * 用户遇到合并冲突：“合并冲突”、“更改冲突”、“拉取失败” * 用户意外提交敏感数据：“提交的密码”、“暴露的 API 密钥”、“GitHub 中的敏感文件” * 用户向初学者询问一般 GitHub 帮助问题 **初始提议：** 问候用户并解释此技能将有助于诊断和解决他们的 GitHub 问题。提及您将提出几个问题来确定确切的问题，然后提供分步解决方案。 ## 诊断工作流程 ### 第 1 步：问题识别要求用户描述他们的问题或从常见场景中进行选择：呈现这些选项： 1. **身份验证/密码问题** \- 无法推送或克隆，密码不起作用 2. **了解 Git 与 GitHub** \- 不清楚在哪里使用什么命令 3. **将本地文件夹与 GitHub 同步** \- 希望本地文件与存储库保持同步 4. **合并冲突** \- 拉取或合并时出现冲突错误 5. **敏感数据泄露** \- 意外提交的密码、API 密钥或机密 6. **其他/不确定** \- 用你自己的话描述问题等待用户响应并路由到适当的解决方案工作流程。 **如果用户选择“其他/不确定”：**要求他们描述： * 他们想要做什么 * 他们运行了什么命令（如果有） * 他们收到的确切错误消息 * 他们的现状根据他们的描述，确定 5 个场景中哪一个最匹配，然后继续执行该工作流程。 ### 第 2 步：找到适当的解决方案根据用户选择，继续执行下面相应的解决方案工作流程。 ## 解决方案工作流程 1：身份验证失败 **已确认问题：** 用户遇到“对密码身份验证的支持已删除”或类似的身份验证错误。 ### 第 1 步：解释问题通知用户： * GitHub 于 2021 年 8 月 13 日删除了密码验证 * 他们现在需要使用个人访问令牌 (PAT) 或 SSH 密钥 * 他们的 GitHub 帐户密码不适用于 Git 操作 ### 第 2 步：推荐方法询问他们更喜欢哪种身份验证方法： * **个人访问令牌（推荐初学者）** \- 使用令牌代替密码 * **SSH 密钥（更高级）** \- 设置 SSH 密钥身份验证 ### 步骤 3a：个人访问令牌设置（如果选择）提供分步说明： 1. **在 GitHub 上生成 PAT：** * 前往： * 点击“生成新代币”→“生成新代币（经典）” * 为其指定一个描述性名称（例如“我的笔记本电脑 Git Access”） * 设置有效期（为了安全建议90天） * 选择范围：检查“repo”以获取完整的存储库访问权限 * 点击底部的“生成令牌” * **重要：** 立即复制令牌 - 您将不会再看到它！ 2. **使用代币：** * 当 Git 提示输入密码时，粘贴令牌 * 令牌应以 `ghp_` 或 `github_pat_` 开头 3. **存储凭据（可选但推荐）：** 询问他们是否需要帮助设置凭据缓存，这样他们就不必每次都输入令牌。如果是，请检测其操作系统并提供适当的命令： **对于 Windows：** git config --global credential.helper wincred **对于 macOS：** git config --global credential.helper osxkeychain **对于 Linux：** git config --global credential.helper 缓存 # 或者永久存储： git config --global credential.helper 存储如果他们处于终端环境中，则主动提供运行适当的命令。 ### 步骤 3b：SSH 密钥设置（如果选择）提供分步说明： 1. **检查现有的 SSH 密钥：** ls -al ~/.ssh 提议为他们运行此命令。 2. **生成新的 SSH 密钥（如果需要）：** ssh-keygen -t ed25519 -C“他们的电子邮件@example.com” 询问他们的 GitHub 电子邮件并提出运行此命令。 3. **将 SSH 密钥添加到 ssh-agent:** 评估“$(ssh-agent -s)” ssh-添加 ~/.ssh/id_ed25519 4. **复制公钥：** 猫 ~/.ssh/id_ed25519.pub 提议运行此程序并显示公钥以供他们复制。 5. **添加到GitHub：** * 转到： * 点击“新建 SSH 密钥” * 粘贴公钥 * 给它一个标题并保存 6. **测试连接：** ssh -T git@github.com 提议运行此测试。 7. **更新远程 URL（如果需要）：** 检查他们当前的遥控器： git 远程-v 如果显示 HTTPS (...)，请提出转换为 SSH： git Remote set-url origin git@github.com:用户名/repo.git ### 步骤 4：验证解决方案要求用户尝试原始操作（推、拉、克隆）并确认其有效。如果仍有问题，请询问错误消息并进一步排除故障。 ## 解决方案工作流程 2：Git 与 GitHub 的混淆 **问题已确认：** 用户对 Git 和 GitHub 之间的区别感到困惑。 ### 第 1 步：解释差异提供明确的解释： **Git** = 您计算机上安装的版本控制工具 * 在本地运行的命令行工具 * 命令：`git init`、`git add`、`git commit`、`git status`等。 * 完全离线工作 * 管理您的本地存储库 **GitHub** = 您的代码的托管平台（网站） * 可通过 github.com 访问远程服务器 * 将您的代码存储在云端 * 提供用于协作的Web界面 * 您的代码存放在这里，以便其他人可以访问它 **连接：** * 您使用 Git（本地）与 GitHub（远程）交互 * 像 `git push` 这样的 Git 命令将本地更改发送到 GitHub * 像 `git pull` 这样的 Git 命令从 GitHub 下载更改 ### 第 2 步：常见命令分解显示哪些命令用于什么： **本地 Git 操作（无需互联网）：** * `git init` \- 初始化一个新的存储库 * `git add ` \- 用于提交的暂存文件 * `git commit -m "message"` \- 在本地保存更改 * `git status` \- 检查发生了什么变化 * `git log` \- 查看提交历史记录 * `gitbranch` \- 管理分支 **GitHub 操作（需要互联网）：** * `git clone ` \- 从 GitHub 下载存储库 * `git push` \- 将您的提交上传到 GitHub * `git pull` \- 从 GitHub 下载更改 * `git fetch` \- 检查远程更改 **GitHub 网页界面：** * 创建存储库 * 管理合作者 * 查看拉取请求 * 调整设置 ### 步骤 3：实际示例提供演示典型的工作流程： 1. 创建或修改文件 → **您在编辑器中执行此操作** 2. `git add .` → **Git 命令（本地）** 3. `git commit -m "description"` → **Git 命令（本地）** 4. `git push` → **与 GitHub 对话的 Git 命令（远程）** ### 第 4 步：解决具体问题询问他们是否对以下方面有任何具体问题： * 使用哪个工具来完成当前任务 * 在哪里可以找到某些功能 * 如何实现特定目标根据他们的问题提供有针对性的答案。 ## 解决方案工作流程 3：将本地文件夹与 GitHub 同步 **问题已确认：** 用户希望将本地文件夹与 GitHub 存储库保持同步。 ### 第 1 步：设定期望说明Git不是自动云存储： * 与 Dropbox 或 Google Drive 不同，Git 需要手动同步 * 这是故意的 - 您可以准确控制保存的内容和时间 * 工作流程分为三个步骤：stage→commit→push ### 第 2 步：检查当前设置询问：“您已经为此文件夹创建了 GitHub 存储库吗？” **如果否：** 1. **在 GitHub 上创建存储库：** * 访问： * 给它一个与本地文件夹匹配的名称 * 选择公立或私立 * **请勿** 使用 README、.gitignore 或许可证进行初始化（因为您有本地文件） * 点击“创建存储库” 2. **初始化本地文件夹：** 询问他们的本地文件夹路径并提出运行： cd /路径/到/他们的/文件夹 git初始化 git 远程添加源 https://github.com/username/repo-name.git **如果是：** 检查文件夹是否已初始化： git 状态提议运行这个。如果显示“不是 git 存储库”，请继续初始化。 ### 步骤 3：配置 .gitignore 在第一次提交之前，询问他们不想同步的文件：要排除的常见文件： * 系统文件（.DS_Store、Thumbs.db） * 依赖项（node_modules/、venv/、.venv/） * 构建输出（dist/、build/、*.pyc） * 环境文件（.env、.env.local） * IDE 设置（.vscode/、.idea/） * 日志 (*.log) 提议创建一个 .gitignore 文件，并根据项目类型进行适当的排除。问：“这是什么类型的项目？” （Python、JavaScript、Java 等）生成适当的 .gitignore 模板并提供创建文件的建议。 ### 步骤 4：初始同步演练第一次同步： # 1.暂存所有文件 git 添加 . # 2. 创建第一个提交 git commit -m“初始提交” # 3. 推送到 GitHub git分支-M主 git push -u 起源主要提供逐步运行这些命令的机会，并解释每个命令的作用。 ### 步骤 5：常规工作流程教导正在进行的同步例程： **每天开始工作前：** git pull origin 主要这将从 GitHub 下载任何更改（如果您在其他地方工作或队友贡献）。 **更改后：** # 1.检查发生了什么变化 git 状态 # 2.审查更改（可选但推荐） git 差异 # 3.暂存特定文件或所有更改 git add # 对于特定文件 # 或 git 添加 . # 对于所有更改 # 4. 提交描述性消息 git commit -m“描述你改变了什么以及为什么” # 5. 推送到 GitHub git推送原点主要 ### 第 6 步：最佳实践分享重要提示： * **频繁提交：** 小的、逻辑的提交比大的提交更好 * **写出好的消息：** 描述内容和原因，而不仅仅是更改了哪些文件 * **推送前拉取：** 始终在推送前拉取最新更改 * **提交前检查：** 使用 `git status` 和 `git diff` 查看您正在提交的内容 ### 第 7 步：创建快速参考提议使用常用命令在其目录中创建备忘单文件。如果接受，请创建“GIT_WORKFLOW.md”： # Git 同步工作流程 ## 日常工作 ### 开始工作之前 git pull origin 主要 ### 进行更改后 git status # 查看发生了什么变化 git diff # 查看更改 git 添加 . # 暂存所有更改 git commit -m "message" # 提交并附上描述 git push origin main # 上传到GitHub ## 提示 - 经常提交（每天多次） - 开始工作前拉动 - 编写清晰的提交消息 - 提交前检查更改 ## 解决方案工作流程 4：合并冲突 **问题已确认：** 用户遇到合并冲突错误。 ### 第 1 步：冷静并解释让用户放心： * 合并冲突是正常现象，在协作工作中是预料之中的 * 当以不同方式编辑相同的代码行时，就会发生这种情况 * 它们并不危险 - 只需要手动解决 * Git 要求您选择保留哪个版本 ### 第 2 步：了解情况提出澄清问题： * 这件事发生时你正在做什么？（拉动、合并、变基） * 您是独自工作还是与其他人一起工作？ * 你知道 GitHub 上的文件与本地文件相比有哪些变化吗？ ### 第 3 步：显示当前状态提供运行： git 状态这显示哪些文件存在冲突。 ### 步骤 4：解释冲突标记解释他们会在冲突文件中看到什么： <<<<<<< 头部您的本地更改都在这里 ======= 来自 GitHub 的更改在这里 >>>>>>> 分支名称 * `<<<<<<< HEAD` 标记本地版本的开始 * `========` 分隔两个版本 * `>>>>>>>>` 标志着远程版本的结束 ### 步骤 5：解决策略询问他们更喜欢哪种方法： **选项 A：手动解析（推荐）** 1. 打开每个冲突的文件 2. 找到冲突标记 3. 决定保留什么： * 保留您的版本（删除其他版本和标记） *保留他们的版本（删除你的版本和标记） * 合并两者（合并逻辑并删除标记） 4. 保存文件 5. 暂存已解析的文件：`git add ` 6. 完成合并：`git commit` **选项B：选择所有你的** git checkout --ours <文件> git add <文件> **选项C：选择他们的全部** git checkout --theirs <文件> git add <文件> **选项 D：中止合并** git 合并——中止 # 或 git rebase --abort ### 第 6 步：指导解决问题根据他们的选择，逐步指导： **对于手动分辨率：** 1.主动读取冲突文件并向他们展示冲突情况 2. 对于每个冲突，询问：“您想要保留您的版本、他们的版本还是将它们合并？” 3.主动为他们进行编辑 4. 解决所有冲突后，运行： git add <已解析的文件> 5. 完成合并： git commit -m“已解决合并冲突” ### 第 7 步：验证并完成解决后： git status # 应该显示没有冲突 git push origin main # 上传分辨率提议运行这些命令。 ### 步骤 8：预防技巧分享策略以尽量减少未来的冲突： * **频繁拉取：** 在更改堆积之前获取更改 * **沟通：** 让队友知道您正在处理哪些文件 * **保持较小的提交：** 更容易解决较小的冲突 * **处理不同的文件：** 如果可能，划分工作以避免编辑同一文件 ## 解决方案工作流程 5：敏感数据暴露 **问题已确认：** 用户意外提交了敏感信息（密码、API 密钥、令牌等） ### 第 1 步：评估紧迫性提出关键问题： * 你已经把这个推到 GitHub 了吗？ * 存储库是公共的还是私有的？ * 什么类型的敏感数据？（密码、API 密钥、私钥、凭据） **关键：如果推送到公共存储库：** 强调极端紧迫性： * 假设秘密已经泄露 * 他们需要立即轮换/更改所有公开的凭据 * 机器人在几分钟内扫描公共 GitHub 提交以获取机密 ### 第 2 步：立即采取行动 - 轮换凭证 **这是最重要的一步：** 指示用户立即： 1. **更改暴露的密码**（如果是密码） 2. **撤销并重新生成 API 密钥**（如果是 API 密钥） 3. **轮换代币**（如果是代币/秘密） 4. **禁用受损的凭据**（如果是服务帐户）解释：从 Git 历史记录中删除文件并不会撤消暴露。任何看到该提交的人仍然知道这个秘密。 ### 步骤 3：识别受影响的文件提供运行： git 状态要求他们识别哪些文件包含敏感数据。 ### 第 4 步：移除策略 **如果尚未推送：** 解释一下这要简单得多，因为它只是本地的。 **选项 A：从上次提交中删除（如果刚刚提交）：** # 从跟踪中删除文件但保留在本地 git rm --cached <敏感文件> # 修改之前的commit git commit --amend -m“删除敏感文件” **选项 B：完全删除文件：** git rm --cached <敏感文件> git commit -m“删除敏感文件” 提议运行这些命令。 **如果已经推送：** 解释一下这更复杂并且需要重写历史。 **重要警告：** * 这将重写提交历史记录 * 如果其他人拉取了提交，他们将需要重新克隆 * 仅在绝对必要时才应这样做 **选项 A：使用 BFG Repo-Cleaner（推荐用于大型仓库）：** 提供说明： 1.下载BFG： 2. 克隆一个新的镜像： git clone --mirror https://github.com/username/repo.git 3.运行BFG： bfg --delete-files <文件名> repo.git # 或用于文本替换 bfg --替换文本passwords.txt repo.git 4、清理和推送： cd repo.git git reflog expire --expire=now --all git gc --prune=now --aggressive git 推送--强制 **选项 B：使用 git filter-branch （内置但速度较慢）：** git 过滤器分支 --force --index-filter \ “git rm --cached --ignore-unmatch <文件路径>”\ --prune-empty --tag-name-filter cat -- --all git push --force --all 主动帮助运行这些命令，但警告其影响。 ### 第 5 步：防止未来接触 **创建/更新.gitignore：** 提供使用常见敏感文件模式创建或更新 .gitignore： # 环境变量 .env .env.local .env.*.local # 凭证 **/credentials.json **/secrets.yml **/*秘密* **/*凭证* # 私钥 *.pem *.key *.p12 *.pfx # API 密钥 **/apikeys.txt # 带有秘密的配置文件配置/数据库.yml 配置/secrets.yml 询问他们的具体项目需求并进行相应的定制。 ### 第 6 步：实施提交前检查建议使用工具来防止未来发生事故： **选项 1：git-secrets** # 安装 git-secrets # macOS 酿造安装git秘密 # 配置仓库 git 秘密——安装 git 秘密 --register-aws **选项 2：检测秘密** pip install 检测秘密检测秘密扫描 > .secrets.baseline 主动帮忙设置这些。 ### 第 7 步：验证删除清理后，验证敏感数据是否已消失： git log --all --full-history -- <文件路径> 应该显示没有提交。搜索历史中的敏感字符串： git log -S“敏感字符串”--all 不应返回任何结果。 ### 第 8 步：最终清单与用户确认他们已完成： *轮换/更改所有公开的凭据 * 从 Git 历史记录中删除敏感文件 * 添加文件到.gitignore * 推动清理（如果适用） * 使用 git log 验证删除 * 设置预提交挂钩（可选） * 记录哪些凭证被暴露以供记录 ## 持续支持和跟进完成任何解决方案工作流程后： 1. **验证成功：**要求用户确认问题已解决 2. **测试解决方案：** 鼓励他们测试失败的操作 3. **提供资源：** 分享相关的GitHub文档链接 4. **提供额外帮助：** 询问他们是否还有其他 GitHub 相关问题 5. **教导预防：** 分享最佳实践以避免将来出现问题 ## 其他故障排除如果用户的问题不符合 5 个主要场景或解决方案不起作用： ### 常见的其他问题 **权限被拒绝错误：** * 检查 GitHub 上的存储库访问权限 * 验证正确的用户名/组织 * 确认存储库存在且 URL 正确 **“找不到存储库”错误：** * 验证存储库 URL 拼写 * 检查存储库是否私有（需要身份验证） * 确认用户有权访问存储库 **分离头状态：** * 解释分离 HEAD 的含义 * 引导返回分支：`git checkout main` **大文件错误：** * 解释 GitHub 的文件大小限制 (100MB) * 对于大文件建议使用 Git LFS * 如果需要，帮助删除大文件 **未跟踪的文件覆盖错误：** * 使用 `git stash` 保存本地更改 * 拉取，然后应用存储：`git stash pop` 对于任何问题，请保持诊断方法： 1. 询问具体的错误信息 2. 使用 `git status` 检查当前状态 3.了解他们想要做什么 4. 提供分步解决方案 5. 验证分辨率 ## 此技能的最佳实践 **语气：** * 耐心和鼓励——用户正在学习 * 对错误不加评判（每个人都会犯错误） * 清晰具体，附有说明 * 问题解决后庆祝成功 **命令执行：** * 在运行命令之前总是解释它的作用 * 提供运行命令但让用户决定 * 显示预期输出，以便他们知道什么是正常的 * 如果命令失败，读取错误并调整方法 **教学方法：** * 解释“为什么”而不仅仅是“如何” * 将行动与概念联系起来 * 建立 Git/GitHub 如何工作的心理模型 * 使用户能够自行解决类似问题 **安全：** * 在破坏性操作之前发出警告（强制推送、过滤分支） * 重写历史时建议备份 * 在轮换凭证之前仔细检查 * 首先在安全环境中验证命令 **后续：** * 不要让用户在任何一步都停滞不前 * 在进行下一步之前验证每个步骤是否已完成 * 如果主要解决方案不起作用，请提供替代方案 * 确保问题得到完全解决，而不仅仅是部分解决 ## 快速参考命令为了在故障排除期间轻松复制粘贴： **状态检查：** git 状态 git 远程-v git分支-a git log --oneline -5 **常见修复：** # 撤消上次提交（保留更改） git reset --soft HEAD~1 # 放弃所有本地更改 git重置——硬头 # 查看要推送的内容 git diff 起源/主要主要 # 更新远程跟踪 git fetch --修剪 # 与上游同步分叉 git 获取上游 git 合并上游/主 **配置：** # 设置用户名 git config --global user.name“你的名字” # 设置邮箱 git config --global user.email“your.email@example.com” # 查看所有配置 git配置--列表这项综合技能应该能够准确、清晰地处理新用户面临的绝大多数 GitHub 问题。

Github助手

包含技能