Web-Dev-For-Beginners GitHub 基础课：从环境配置到开源协作的完整 Git 实战指南

本篇技术指南源自开源课程 Web-Dev-For-Beginners 第一部分“开始使用 Web 开发”中的《Introduction to GitHub》一课（其英文原文位于 1-getting-started-lessons/2-github-basics/README.md，本仓库还收录了数十种语言译本，如 孟加拉语版）。课程以“24 节课、12 周、从零成为 Web 开发者”为目标，而本节正是连接个人编码与世界协作的起点。读完本文，你将能独立完成 Git 安装与身份配置、在 GitHub 上创建第一个仓库、熟练运用 git add / commit / push 的每日循环，并掌握 Fork、分支、Pull Request 这一整套开源协作工作流，最终把代码贡献给全世界开发者共同维护的项目。

本节课程位于 1-getting-started-lessons/README.md 所定义的“开始使用 Web 开发（Getting Started with Web Development）”单元中，与编程语言入门、无障碍基础并列，属于不依赖具体项目的“职业开发者素养”部分。它要回答三个核心问题：如何追踪本机工作、如何与他人协作开发项目、以及如何向开源软件做贡献。

课程地图：今天的 GitHub 冒险

本课的官方课程文档用一张旅程图勾勒了学习路径，全课可划分为三个阶段：

journey
    title GitHub 入门学习路线
    section 环境准备
      安装 Git: 4: 你
      创建账号: 5: 你
      第一个仓库: 5: 你
    section 掌握 Git
      本地变更: 4: 你
      提交与推送: 5: 你
      分支: 4: 你
    section 协作
      Fork 项目: 4: 你
      Pull Request: 5: 你
      开源贡献: 5: 你

课前准备：一次配置，长期受益

在开始任何激动人心的内容之前，需要先把电脑调整为“可进行 GitHub 魔法”的状态。这套准备工作只需要做一次，之后便可贯穿整个编码生涯。

检查 Git 是否已安装

Git 是一种版本控制系统（Version Control System），它像一位超聪明的助手，能记住你对代码做出的每一次修改。用终端执行如下命令检查：

git --version

如果命令报错或未显示版本号，说明 Git 尚未安装，请前往 Git 官方下载页获取对应平台的安装包；Linux 用户也可以通过包管理器安装（例如 Debian/Ubuntu 系使用 sudo apt-get install git，Fedora 系使用 sudo yum install git，相关速查可参考仓库中的 Git-Basics/README.md）。

向 Git 介绍你自己

安装完成后，必须配置你的身份。这些信息会附加在你每一次 git commit 上，因此请选择一个愿意公开分享的用户名和邮箱：

git config --global user.name "your-name"
git config --global user.email "your-email"

--global 表示全局生效。检查配置是否成功：

git config --list

此外还需要三样东西：一个 GitHub 账号、一个代码编辑器（如 Visual Studio Code）、以及一个终端（或命令行提示符）。请到 GitHub 官网注册账号，或登录后完善个人资料。

💡 现代实践：为免去反复输入密码，建议优先配置 SSH 密钥或使用 GitHub CLI 进行更便捷的认证（下文“安全实践”一节会给出具体命令）。

课前准备清单

• 本机（笔记本或 PC）上有一个包含代码项目的文件夹；
• GitHub 上有一个公开仓库，用于演练“向他人项目贡献代码”的流程。

让代码安全无虞：现代安全实践

安全习惯就像给车上锁：简单、自然，却能保护你长期的心血。课程要求从一开始就用现代、安全的方式操作 GitHub，特别强调以下几点最佳实践：

安全领域	最佳实践	为什么重要
认证（Authentication）	使用 SSH 密钥或 Personal Access Token	密码安全性较低，且正在被逐步淘汰
双因素认证（2FA）	在 GitHub 账号上开启两步验证	为账号安全增加一层额外保护
仓库安全	绝不提交敏感信息	API 密钥与密码永远不应出现在公开仓库中
依赖管理	开启 Dependabot 接收更新	让依赖保持安全与最新

⚠️ 关键安全提醒：永远不要把 API 密钥、密码或其他敏感信息提交到任何仓库。请使用环境变量（Environment Variables）与 .gitignore 文件保护敏感数据。

课程给出的“现代认证设置”命令如下：

# 生成 SSH 密钥（使用现代的 ed25519 算法）
ssh-keygen -t ed25519 -C "[e-mail]"

# 让 Git 改用 SSH 认证
git remote set-url origin [e-mail]:username/repository.git

💡 专业提示：SSH 密钥免去了反复输入密码的麻烦，也比传统认证方式更安全。一个值得养成的习惯是：在项目根目录维护一份 .gitignore，把本地的笔记文件、临时产物、密钥文件等不应进入公开仓库的内容排除在外，.gitignore 的模板可在 Git 官方维护的 gitignore 模板集中获取，也可以用各种 .gitignore 生成工具按需创建。

像专业人士一样管理代码：本地 Git 工作流

把 Git 想象成一本“可穿越时间的笔记本”：它记住每一个修改，也允许你随时回退。课程给出的核心工作流可以浓缩为下面的流程图：

flowchart TD
    A[📁 项目文件] --> B{它是 Git 仓库吗?}
    B -->|否| C[git init]
    B -->|是| D[做出修改]
    C --> D
    D --> E[git add .]
    E --> F["git commit -m '说明信息'"]
    F --> G[git push]
    G --> H[🌟 代码上线 GitHub!]
    H --> I{想与人协作吗?}
    I -->|是| J[Fork 并 Clone]
    I -->|否| D
    J --> K[创建分支]
    K --> L[做出修改]
    L --> M[Pull Request]
    M --> N[🎉 完成贡献!]

任务：创建你的第一个仓库

这是全课最重要的一次实操。课程官方为每个步骤提供了配套讲解视频，下面是完整的分步指引。

第 1 步：在 GitHub 上创建仓库。 进入 GitHub 首页，点击亮绿色的 New 按钮（或右上角的 + 号），选择 New repository，然后依次完成：

1. 为仓库命名——取一个对你有意义的名字；
2. （可选）添加描述，帮助他人理解项目用途；
3. 选择 Public（所有人可见）或 Private（仅自己可见）；
4. 勾选“添加 README 文件”——README 相当于项目的门面首页；
5. 点击 Create repository 完成创建。

第 2 步：进入项目文件夹。 打开终端并切换到项目目录：

cd [name of your folder]

[name of your folder] 替换为项目文件夹的实际名称。这条命令等价于在文件管理器中双击进入某个文件夹。

第 3 步：把普通文件夹变成 Git 仓库。

git init

执行后 Git 会在项目中创建一个隐藏的 .git 目录（平时不可见），你的文件夹从此升级为“仓库”，能够追踪每一次修改。

第 4 步：查看仓库当前状态。

git status

输出可能类似：

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)

	modified:   file.txt
	modified:   file2.txt

解读：红色文件表示已修改但尚未准备好保存；绿色文件（后续会出现）表示已进入“暂存区”待保存。git status 是你的最佳拍档——任何时候不确定发生了什么，就执行它。

第 5 步：暂存（staging）文件。

git add .

. 表示“把本文件夹里的所有改动纳入下一次保存”。也可以只暂存特定文件或目录：

git add [file or folder name]

这样做的好处是能把相关联的改动组织成逻辑单元，让历史更易读懂。如果改变主意，可以取消暂存（不会删除任何工作，只是把文件移出“待保存”名单）：

# 取消暂存全部
git reset

# 只取消暂存某一个文件
git reset [file name]

第 6 步：永久保存——完成第一次提交。

git commit -m "first commit"

🎉 恭喜！第一次 commit 完成。Git 在这一刻对所有已暂存文件拍了一张“快照”，并分配了唯一 ID，项目的完整历史正式启动。后续提交请用更描述性的信息，例如把 "updated stuff" 换成 "Add contact form to homepage" 或 "Fix navigation menu bug"——未来的你会感谢现在的你。

第 7 步：把本地仓库连接到 GitHub。

git remote add origin https://github.com/username/repository_name.git

（把 URL 替换成你仓库的真实地址。）这条命令在本地项目与 GitHub 仓库之间建立了连接：origin 只是远程仓库的昵称，相当于把联系人存进通讯录。更省事的方式是使用 GitHub CLI 一步完成“创建 + 推送”：

gh repo create my-repo --public --push --source=.

第 8 步：把代码推送到 GitHub。

git push -u origin main

• 本地提交会从你的电脑上传到 GitHub；
• -u 参数建立持久关联，之后只需 git push 即可；
• main 是你的主分支名称（相当于“主文件夹”）。

💡 如果你的默认分支名不同（例如旧式 master），请改用该名称。可用 git branch --show-current 查看当前分支名。

第 9 步：建立每日编码节奏。 从此以后，每次改动项目都只需循环三连：

git add .
git commit -m "describe what you changed"
git push

这就像游戏里的“多存档点”：改动满意就提交；想尝试危险操作也无需担心，随时可以回到最近一次提交。

第一次仓库实践回顾

完成上述流程后，可以思考三个问题：第一次在 GitHub 上看到自己代码是什么感受？哪一步最困惑、哪一步意外轻松？能否用自己的话讲清 git add、git commit、git push 的区别？仓库状态在每一步之间流转的关系可用下面的状态图概括：

stateDiagram-v2
    [*] --> LocalFiles: 创建项目
    LocalFiles --> Staged: git add .
    Staged --> Committed: git commit
    Committed --> GitHub: git push
    GitHub --> [*]: 成功! 🎉

    note right of Staged
        文件已准备好保存
    end note

    note right of Committed
        快照已生成
    end note

现代 Git 工作流与提交信息规范

为了让提交历史更专业，课程建议尽早采纳以下三种现代实践：

• Conventional Commits（约定式提交）：使用 feat:、fix:、docs: 等标准前缀格式化提交信息；
• Atomic commits（原子提交）：让每一个提交只代表一个单一逻辑变更；
• Frequent commits（高频提交）：宁可多次提交、附带描述性信息，也不要攒成大而零散的提交。

如何写出优质提交信息？ 一条出色的提交主题应当能完整填入这个句子：“如果应用此提交，它将 <你的主题内容>”。主题行使用祈使句、一般现在时——写 change，而不是 changed 或 changes。正文（可选）同样使用祈使句现在时，重点解释变更的动机并与旧行为作对比——你解释的是“为什么”，而非“怎么做”。

✅ 练习：花几分钟在 GitHub 上逛逛，找出一条真正出色的提交信息与一条过于简略的提交信息，思考哪些信息在提交中是最重要、最有用的。

与人协作：GitHub 的魔法时刻

把代码放到 GitHub 的根本原因，就是为了与他人协作——这也是 Google、微软等团队每天在用的工作流。完整的协作链路如下：

flowchart LR
    A[🔍 找到项目] --> B[🍴 Fork 仓库]
    B --> C[📥 Clone 到本地]
    C --> D[🌿 创建分支]
    D --> E[✏️ 做出修改]
    E --> F[💾 提交修改]
    F --> G[📤 推送分支]
    G --> H[🔄 创建 Pull Request]
    H --> I{维护者评审}
    I -->|✅ 通过| J[🎉 合并!]
    I -->|❓ 要求修改| K[📝 更新代码]
    K --> F
    J --> L[🧹 清理分支]

让仓库看起来专业且友善

在仓库中进入 Insights > Community，可以查看你的项目相对 GitHub 社区推荐的“优秀仓库实践”差距如何。一个组织良好、文档完善的仓库如同整洁迎客的门店。课程给出了让仓库“出彩”的清单：

该添加什么	为什么重要	它能为你带来什么
项目描述 Description	第一印象很重要	人们立刻知道你的项目做什么
README	项目的门面	为新访客充当友好向导
贡献指南 Contributing Guidelines	表明你欢迎帮助	人们清楚如何帮助你
行为准则 Code of Conduct	营造友好空间	每个人都感到被欢迎参与
许可证 License	法律清晰	别人知道如何使用你的代码
安全策略 Security Policy	表明你负责任	体现专业实践

💡 GitHub 为以上文件均提供模板：新建仓库时勾选相应复选框即可自动生成这些文件。

一个绝佳的直观验证是：本仓库根目录本身就齐备了这份清单——README.md（项目门面）、CONTRIBUTING.md（贡献指南）、CODE_OF_CONDUCT.md（行为准则）、LICENSE（许可证）、SECURITY.md（安全策略）一应俱全，这正是“专业仓库”的真实范例。新贡献者在查看你的代码之前，往往先通过这批文件判断项目是否值得投入时间，因此它们也直接服务于新成员的 onboarding。

此外，GitHub 还提供了大量现代功能：自动化与 CI/CD 方面有 GitHub Actions（自动化测试与部署）和 Dependabot（自动依赖更新）；社区与项目管理方面有 GitHub Discussions（议题之外的社区讨论）、GitHub Projects（看板式项目管理）以及 Branch protection rules（分支保护规则，用于强制代码质量）。

任务：合并一段他人的代码

贡献文档（Contributing Guidelines）解释了你期待何种贡献以及流程如何运作。要让别人能贡献到你的仓库，通常需要经历：Fork 你的仓库（在你的仓库与他人 GitHub 主页之间创建副本）→ Clone 到本地 → 为其工作创建分支 → 把改动聚焦在一个领域（一次只改一件事，合并的成功率更高；如果对方同时提交了 bug 修复、新特性与测试更新，而你只想或只能合并其中一部分，会非常被动）。

这里顺带强调一个实践要点：自己开发时同样要为每项工作单独建分支。任何提交都会落在当前“检出（checked out）”的分支上，用 git status 可随时确认自己身处哪个分支。

下面完整过一遍贡献者的工作流（假设已经 Fork 并 Clone 了仓库）：

1. 创建分支。

git branch [branch-name]

💡 现代做法：一步完成创建并切换新分支——git switch -c [branch-name]。

2. 切换到工作分支。

git switch [branch-name]

git switch 是切换分支时对旧命令 git checkout 的现代替代，语义更清晰、对新手更安全。

3. 完成工作并提交。

git add .
git commit -m "my changes"

⚠️ 提交信息质量：务必给提交起一个好名字——既为了你自己，也为了你正在协助的仓库维护者。请具体说明你改了什么！

4. 把工作与 main 分支合并。 完成工作后，主分支可能已经前进，因此先把它更新到最新：

git switch main
git pull

随后回到工作分支执行合并，让潜在的冲突（Git 无法自动合并的情形）发生在你的工作分支上而不是主分支上：

git switch [branch-name]
git merge main

git merge main 会把 main 上的全部改动带入你的分支。若产生冲突，VS Code 会高亮标出 Git“困惑”的位置，你只需编辑相应文件、保留正确内容即可。

💡 现代替代：想要更干净的线性历史，可使用 git rebase main。它会把你的提交“重放”到最新 main 分支之上。

5. 把工作送到 GitHub。 这包含两件事：推送分支 + 打开 PR（Pull Request）：

git push --set-upstream origin [branch-name]

上述命令会在你的 fork 仓库上创建对应分支。

打开 Pull Request

之后进入 GitHub 上你 Fork 的仓库页面，页面会提示是否创建新 PR。点击后进入 PR 编辑界面，可以调整提交信息的标题并补充更贴切的描述。随后，被 Fork 仓库的维护者会看到该 PR——祈祷他们认可并合并它，你就正式成为一名贡献者。也可用 GitHub CLI 创建 PR：

gh pr create --title "Your PR title" --body "Description of changes"

PR 最佳实践清单：

• 使用 Fixes #123 这类关键词把 PR 与相关 issue 关联起来；
• UI 变更请附带截图；
• 指定具体评审人；
• 进行中的工作请使用 Draft PR；
• 请求评审前确认所有 CI 检查均已通过。

合并后的清理。 PR 成功合并后，本地分支与远端分支都应及时删除。本地删除：

git branch -d [branch-name]

然后前往 Fork 仓库的 GitHub 页面，删除你推送上去的远端分支。

补充概念：为什么叫 Pull Request？ 你其实是想把改动“推送”进项目，但维护者（项目所有者）或核心团队必须在改动并入 main 之前先行审议，因此你本质是在向维护者“请求一个关于变更的决策”。PR 是集中对比与讨论分支差异的场所，可附评审、评论、集成测试等。一份优秀 PR 遵循与提交信息相近的规则；若你的工作修复了某个 issue，可在 issue 跟踪器中引用它，格式为 # 加 issue 编号，例如 #97。

最后，当你的 PR 合并后，本地分支也应通过 git pull 拉取对应远端分支上的全部新提交，保持本地与远端同步。

协作技能自检

• Fork 与 Pull Request 的概念现在清晰了吗？
• 关于分支操作，你最想再练哪一点？
• 向别人的项目贡献代码，你的信心如何？

mindmap
  root((Git 协作))
    Branching
      特性分支
      Bug 修复分支
      实验性工作
    Pull Requests
      代码评审
      讨论
      测试
    Best Practices
      清晰的提交信息
      小而聚焦的改动
      良好的文档

参与开源：创造你的影响力

开源社区本质上是一场“全球最大的团体拥抱”：大多数项目都热切欢迎新人，并专门设有标注 good first issue 的 issue，供初来者练手；维护者看到新贡献者时往往满怀欣喜，因为他们记得自己的第一步。

完整的开源贡献流程如下：

flowchart TD
    A[🔍 探索 GitHub] --> B[🏷️ 找到 good first issue]
    B --> C[📖 阅读贡献指南]
    C --> D[🍴 Fork 仓库]
    D --> E[💻 搭建本地环境]
    E --> F[🌿 创建特性分支]
    F --> G[✨ 做出你的贡献]
    G --> H[🧪 测试你的修改]
    H --> I[📝 写好清晰的提交]
    I --> J[📤 推送并创建 PR]
    J --> K[💬 参与反馈沟通]
    K --> L[🎉 合并成功! 你是一名贡献者!]
    L --> M[🌟 寻找下一个 issue]

寻找“对新手友好”仓库的推荐方式，就是按 good-first-issue 标签进行搜索。

把仓库代码复制到本地

第一步，在 GitHub 上找到一个你感兴趣、希望为之贡献改动的仓库（repo），并把它的内容复制到本机。复制代码有几种途径：通过 HTTPS、SSH 或 GitHub CLI 来“克隆（clone）”仓库内容。

打开终端，像这样克隆仓库：

# 使用 HTTPS
git clone https://github.com/ProjectURL

# 使用 SSH（需要预先配置 SSH 密钥）
git clone [e-mail]:username/repository.git

# 使用 GitHub CLI
gh repo clone username/repository

进入项目目录开始工作：

cd ProjectURL

除了本地开发，还可以用多种方式打开整个项目：

• GitHub Codespaces：GitHub 的云端开发环境，在浏览器中直接运行 VS Code；
• GitHub Desktop：面向 Git 操作的图形化桌面应用；
• GitHub.dev：在任意 GitHub 仓库页面按下 . 键，即可在浏览器中打开 VS Code；
• VS Code + GitHub Pull Requests 扩展：直接在编辑器内完成 PR 全流程。

最后一种方式，是把代码以 ZIP 压缩包的形式整包下载。

GitHub 上更多值得了解的功能

你可以对 GitHub 上任意公开仓库执行 Star、Watch 与 Fork 操作：Star 过的仓库可在右上角下拉菜单中找到，相当于“为代码收藏夹”；项目通常拥有 Issue 跟踪器（默认在 Issues 标签页），供人们讨论与项目相关的问题；Pull Requests 标签页则用于讨论与评审进行中的改动。项目还可能依托论坛、邮件列表，或 Slack、Discord、IRC 等聊天渠道展开讨论。

值得探索的现代功能还包括：

• GitHub Discussions：内置的社区论坛；
• GitHub Sponsors：在经济上支持维护者；
• Security 标签页：漏洞报告与安全公告；
• Actions 标签页：查看自动化工作流与 CI/CD 流水线；
• Insights 标签页：贡献者、提交与项目健康度分析；
• Projects 标签页：GitHub 内置的项目管理工具（如看板）。

✅ 动手练习：在你的新仓库里四处转转，试试编辑设置、为仓库补充信息、创建一个项目（例如看板）、配置 GitHub Actions 实现自动化。

课程配套挑战与作业

协作挑战： 找一位朋友（或那位总问你在“捣鼓电脑”什么的家人）共同开启一次协作编码之旅：创建项目 → 让对方 Fork → 创建若干分支 → 像专业人士一样合并改动。两人同时改同一行时大概率会笑出声，但真正难忘的是共享第一次成功合并的“aha!”时刻。如果暂时没有搭档，GitHub 社区充满友善的人，请寻找带 good first issue 标签的仓库——它们无异于在说“嘿，新手们，来和我们一起学吧”。

课后作业： 完成 GitHub Skills 的 Introduction to GitHub 交互式课程，在安全、有引导的环境里练习本次所学全部内容，完成后还能获得徽章。进阶挑战包括：为账号配置 SSH 认证（告别密码）、用 GitHub CLI 处理日常 Git 操作、创建带 GitHub Actions 工作流的仓库、通过云端编辑器（Codespaces）打开本仓库练手。

Agent 挑战（Copilot Agent Challenge）： 本课还内置了一道面向 AI Agent 的综合任务——创建一个公开的“Web 开发资源”仓库，要求包含分类整理（HTML/CSS/JavaScript 等）的 README、许可证/贡献指南/行为准则等社区标准文件；创建至少两个特性分支（分别添加 CSS 与 JavaScript 资源），用描述性提交信息逐个提交，再通过 Pull Request 合并回 main；同时启用 Issues、Discussions，并配置基础 GitHub Actions 工作流做自动化检查。

从本课到熟练：分阶段成长清单

课程给出了一个循序渐进的 GitHub 熟练度时间线，可按自己的节奏勾选完成。

未来 5 分钟： 为本仓库与你感兴趣的另外 3 个项目点 Star；开启双因素认证；为第一个仓库写好简单 README；关注 5 位激励你的开发者。

这一小时： 完成课后测验并复盘；配置 SSH 密钥实现免密认证；用一条好信息完成第一次有意义的提交；浏览 Explore 标签发现趋势项目；练习 Fork 并提交一个小改动。

这一周： 完成 GitHub Skills 系列课程；向开源项目提交第一个 PR；用 GitHub Pages 建立作品展示站点；加入感兴趣项目的 Discussions；创建带完整社区标准文件（README、License 等）的仓库；尝试用 Codespaces 云端开发。

这一个月： 向 3 个不同开源项目提交贡献；指导一位 GitHub 新手；用 GitHub Actions 搭建自动化工作流；构建展示个人贡献的作品集；参与 Hacktoberfest 等社区活动；最终成为“别人向你仓库提交代码”的维护者。

总结与延伸阅读

本课的核心收获可概括为一条主线：Git 管理本地历史（init → add → commit → push），GitHub 承载协作与开源（Fork → 分支 → PR → 合并）。仓库中的《Git-Basics》文档正好可作为命令速查补充：Git-Basics/README.md 汇总了 git init/git clone/git status/git add/git commit/git push/git pull 与分支合并、远程仓库管理、git log/git diff 等高频命令的含义对比，并给出了 Git 与 GitHub 的概念区分：Git 是 2005 年发布的开源软件、本地安装的命令行版本控制工具；GitHub 是 2008 年上线、托管于 Web 的云服务与图形界面，二者一个专注版本控制与代码共享，一个专注集中式源码托管。

如果你想继续深入了解仓库中的相关材料，可以查看：

• 本节英文原文：1-getting-started-lessons/2-github-basics/README.md
• 本单元总览与三位课程作者：1-getting-started-lessons/README.md
• 仓库社区规范文件的真实样例：CONTRIBUTING.md、CODE_OF_CONDUCT.md、LICENSE、SECURITY.md
• Git 命令速查补充：Git-Basics/README.md

每一位你仰望的开发者，都曾是紧张地第一次点击“create pull request”的初学者。当你理解了 add / commit / push 与 Fork / PR 的协作闭环，就已经握住了全球开发者社区最通用的“秘密语言”。任何大型开源项目都始于某个人的第一次提交——问题从来不是“你是否会产生影响”，而是“哪个项目会最先受益于你独特的视角”。