GitHub：实用教程（从入门到精通）
Git 与 GitHub 的区别
Git 是运行在本地设备上的分布式版本控制系统，用来记录文件变化、创建分支、比较差异和回退版本。GitHub 是提供远程仓库、协作工具和项目服务的平台；它可以托管 Git 仓库，但不等同于 Git 本身。
一个常见工作流是：在电脑上用 Git 修改和提交，再把提交推送到 GitHub 的远程仓库；团队成员通过分支、Pull Request 和 Issue 协作。也可以只在本地使用 Git，或将仓库托管到其他兼容 Git 的平台。
理解两者的边界有助于排错：提交失败可能来自本地 Git 配置，推送失败可能与远程地址或权限有关，网页上的审核、讨论和自动化则属于托管平台的功能。
注册账号与安装 Git
- 在 GitHub 官方网站注册账号并完成邮箱验证。用户名会影响个人主页地址，建议选择长期使用、容易辨认的名称。
- 从 Git 官方安装包或操作系统的可信软件源安装 Git。安装后在终端执行
git --version，确认命令可用。 - 首次提交前设置提交作者信息，例如
git config --global user.name "Your Name"和git config --global user.email "[email protected]"。这里的邮箱应按自己的 GitHub 隐私设置决定是否使用公开地址。
登录 GitHub 网页与让 Git 推送代码是两件事。命令行认证可使用 SSH 密钥或个人访问令牌（PAT）等官方支持方式；不要把密码、令牌或私钥写入仓库、脚本、截图和 URL。令牌一旦泄露，应立即在账户设置中撤销并检查最近活动。
仓库、提交、分支与远程
| 概念 | 作用 |
|---|---|
| 仓库 | 保存项目文件、提交历史、分支、标签和协作记录的目录或远程项目。 |
| 提交 | 一次有说明的版本记录，描述一组已经确认的文件变化。 |
| 分支 | 从某个提交继续发展的独立线路，适合隔离功能、修复或实验。 |
| 远程 | 本地仓库记录的远程仓库地址，常见名称是 origin。 |
可以把工作区、暂存区、本地提交和远程仓库看成连续的确认过程：先修改文件，再用 git add 选择变化，用 git commit 记录版本，最后用 git push 推送。拉取他人更新前先查看本地未提交变化，避免把无关修改混在一起。
提交信息应说明动词和目的，例如“修复登录页错误提示”，不要只写“更新”或“修改”。小而完整的提交更容易审查、回退和定位问题。
看懂一个开源项目
打开项目后，先看 README、许可证、贡献指南和安全政策，再判断项目是否适合自己的需求。Star 可以表示收藏或关注，Watch 控制通知，Fork 是在自己的账户下创建可独立修改的副本，不能简单等同于项目质量或官方认可。
- 确认项目解决的问题、适用平台和最近维护情况。
- 查看安装步骤、示例配置和已知限制，先用非敏感数据试运行。
- 阅读许可证，区分个人使用、修改、再分发和商用时的要求。
- 从 Issues、Pull Requests 和 Releases 了解已知问题、变更和维护者的处理方式。
开源不等于没有条件，也不等于一定有人提供技术支持。下载第三方构建产物时核对发布页、校验信息和项目说明，不运行来源不明的脚本或二进制文件。
GitHub 搜索方法
搜索时先写清楚目标：找项目、找代码、找 Issue，还是找某个用户维护的仓库。再使用限定符缩小范围，例如 in:name、in:readme、language:TypeScript、user:octocat、topic:security 和 is:issue。
Stars、更新时间和语言可以帮助排序，但不是可靠的质量证明。对于依赖或生产项目，还要看许可证、发布节奏、开放问题、测试和安全公告。代码搜索的可见范围受登录状态、仓库权限和 GitHub 当前搜索能力影响。
可把搜索条件保存为自己的工作笔记，但不要把含有私有仓库名称、客户名称或内部路径的查询发布到公开环境。
阅读源码的基本路径
- 先画出项目地图：入口文件、构建脚本、配置、测试和文档分别在哪里。
- 按照 README 跑通一个最小示例，记录实际使用的版本和环境。
- 从用户能触发的一个功能开始，找到入口、核心函数和输出位置。
- 只追一条完整路径，再回看相关提交、Issue、Pull Request 和 Blame 记录。
- 把不确定的推断写成问题，用测试或小范围修改验证，不凭文件名猜测全部行为。
网页上的快捷键、代码搜索和文件历史可以减少跳转成本，但不同页面和界面版本的快捷键可能变化。阅读第三方代码时，优先在隔离环境运行，避免项目脚本接触不必要的个人文件和凭据。
提交第一个 Pull Request
- 先阅读项目的贡献指南、行为准则和 Issue 讨论，确认问题尚未被重复解决。
- Fork 项目或获得直接分支权限后，将仓库克隆到本地；远程地址只使用自己的账号和可信项目地址。
- 从目标分支创建描述清楚的工作分支，完成一个范围明确的修改，并运行项目要求的测试。
- 检查差异，确认没有调试日志、密钥、构建产物或无关格式化，再提交并推送分支。
- 创建 Pull Request，写明问题、方案、验证方式和已知限制，按维护者意见补充提交。
Pull Request 是讨论和审查入口，不是自动合并按钮。尊重维护者的范围判断；如果需求变化，先更新说明再修改代码。不要为了通过检查删除测试、伪造结果或绕过分支保护。
GitHub Actions 自动化
GitHub Actions 通过仓库中的工作流文件响应推送、Pull Request、定时任务或手动触发，常见用途包括运行测试、构建项目、发布制品和部署静态站点。
工作流应明确触发条件、权限范围、运行环境、依赖版本和失败处理。密钥放在 GitHub Secrets 或环境提供的安全存储中，不要写进 YAML、日志和构建产物。第三方 Action 需要核对维护者、版本和权限，并尽量固定到可信版本。
公开仓库和私有仓库的分钟数、并行限制、存储和计费政策可能变化。查看当前账户和组织的用量页面，不把网上旧教程中的免费额度当成永久规则。
GitHub Pages 静态站点
GitHub Pages 适合发布由 HTML、CSS、JavaScript 或静态站点生成器产生的内容。发布来源可以是分支目录或 Actions 工作流，具体选项取决于仓库类型和当前设置。
- 先确认仓库内容不含密钥、个人资料和不应公开的构建文件。
- 在仓库设置中选择 Pages 的发布来源，等待构建完成。
- 访问生成地址并检查资源路径、HTTPS、404 页面和移动端布局。
- 修改发布分支或工作流前，保留可回退的提交和部署记录。
Pages 是静态托管，不等于提供后端数据库、私有 API 或服务器端执行环境。自定义域名、缓存、访问控制和合规要求应按当前 GitHub 文档及域名服务商设置处理。
常见错误与排查
| 现象 | 先检查 |
|---|---|
| 认证失败 | 确认远程地址、SSH 密钥或令牌状态，避免继续使用已撤销或泄露的凭据。 |
| 推送被拒绝 | 查看分支保护、远程新提交和权限，不要直接强制推送共享分支。 |
| 合并冲突 | 先保存当前工作，理解双方修改，再逐文件解决并重新运行测试。 |
| Actions 失败 | 查看具体步骤日志、运行环境、依赖版本和权限，不把整段日志中的令牌复制到公开 Issue。 |
遇到陌生错误时，先记录命令、分支、提交和完整错误上下文，再到官方文档或项目 Issue 搜索。不要把账号密码、私钥、完整环境变量和客户数据贴到公共讨论中。
免费功能与额度说明
GitHub 的个人账户、公开仓库、协作、Actions、Pages、Codespaces 和 Copilot 等功能有不同的资格、用量和计费规则。是否免费取决于账户类型、仓库可见性、组织政策、地区以及当前产品计划。
使用前查看账户的 Billing、Usage 和对应产品文档，特别是 Actions 分钟数、Artifacts 存储、Codespaces 时长、私有仓库协作权限和 Copilot 计划。额度不足时，服务可能暂停、限制或要求升级，不应把旧文章中的数字直接套用到当前账户。
个人主页与 Profile README
创建一个与 GitHub 用户名完全相同的公开仓库，并在根目录放置 README.md，GitHub 可以把它显示在个人主页的 Profile README 区域。内容可包括技术方向、代表项目、联系方式和正在学习的主题。
主页更像可维护的项目索引，不必堆满徽章或夸张承诺。链接应指向实际可访问的项目，技术栈注明使用范围，联系方式避免公开不必要的个人信息。每隔一段时间检查失效链接、过时项目和泄露风险。
多人协作与分支策略
小团队可以采用主分支加短期功能分支；维护多个版本时，可以额外设置发布分支或长期支持分支。关键不在分支名称，而在于团队明确谁能合并、哪些检查必须通过、如何发布和如何回滚。
- 开始工作前同步目标分支，避免长时间偏离主线。
- 每个 Pull Request 只解决一个清楚的问题，并在说明中写验证结果。
- 用保护规则、必需审查和自动化检查降低误合并风险。
- 合并后删除已经完成的短期分支，保留标签和发布记录。
涉及生产系统、客户资料或安全配置时，先定义权限边界和应急联系人。协作流程不能替代备份、日志和人工确认。
GitHub 常用速查
| 目标 | 常用动作 |
|---|---|
| 开始项目 | git init、git clone、git status |
| 记录变化 | git add、git diff、git commit |
| 同步远程 | git fetch、git pull、git push |
| 分支操作 | git switch -c feature/name、git log --oneline |
命令只说明动作，不代表可以跳过检查。执行删除、重置、强制推送等不可逆或高风险命令前，先确认当前分支、远程和备份；团队仓库遵循项目贡献指南中的命令和流程。
Git、GitLab、Gitee 等平台对比
Git 是版本控制工具；GitHub、GitLab、Gitee 等是提供远程仓库和协作能力的平台。选择平台时，比较仓库可见性、组织权限、代码审查、CI/CD、制品、Pages、数据区域、合规和迁移成本。
项目的许可证和贡献流程独立于托管平台。迁移仓库前检查 Issue、Pull Request、Release、Actions、Wiki、LFS、Webhook 和包注册表是否需要单独导出或重建。平台名称相近不代表功能、限制和服务条款相同。
官方入口
| 地址 | 链接 |
|---|---|
| GitHub 与 Git | |
| 设置 Git | |
| 认证与凭据安全 | |
| 代码搜索语法 | |
| Fork 与 Pull Request | |
| GitHub Actions | |
| GitHub Pages |
使用声明
本文由 MENTUKEJI 根据项目官网、官方文档及公开资料整理。工具功能、价格、授权方式及服务条款可能随时调整，请以官方最新信息为准。
引用本文内容请注明来源并保留原文链接；如需全文转载，或发现内容错误、版权及授权问题，请联系：[email protected]。