Web-Dev-For-Beginners GitHub 基础课精讲：从 Git 安装配置、第一次提交到 Fork 协作与开源贡献的完整实战

本篇文章是《Web-Dev-For-Beginners》入门系列（1-getting-started-lessons）中「Introduction to GitHub」一课的中文深度解读。原课作为为期 12 周、共 24 课的全栈前端课程的第 2 课，面向零基础学习者系统讲解 Git/GitHub 的完整链路：本地代码跟踪、远程仓库同步、分支与 Pull Request 协作，以及向开源项目提交贡献的标准流程。读完本文，你将能独立完成「创建仓库 → git init/add/commit → 关联远端并 push → 通过 Fork + 分支 + PR 参与他人项目」的完整闭环，并掌握现代认证方式、Commit Message 规范与仓库社区标准等进阶实践。

---

一、课程定位：GitHub 在本项目中的角色

在 1-getting-started-lessons/README.md 中，「Introduction to GitHub」与编程语言导论、无障碍基础一起，构成课程的“非项目型前置知识”章节。它之所以被放在课程最前面，是因为后续所有的实战项目——3D 玻璃容器（Terrarium）、打字游戏、浏览器扩展、太空射击游戏、银行应用等——都依赖 Git 仓库来保存、分享与迭代代码。

本节课要掌握的三件事非常明确：

• 跟踪你在自己电脑上完成的工作（本地版本管理）；
• 与他人共同开发项目（远程协作）；
• 向开源软件贡献代码（Fork + Pull Request）。

本课原始文档存在于英文目录 1-getting-started-lessons/2-github-basics/README.md，同时经自动化翻译保存在 translations/bg/1-getting-started-lessons/2-github-basics/README.md 等 50 余种语言目录中，配套示意图统一存放于 translated_images 与 sketchnotes 目录——这正是本仓库对“多语言协作与开源生态”的真实演示。

---

二、环境准备：安装与配置 Git

2.1 检测并安装 Git

Git 本质上是一个“超级聪明的助手”，会记住你对代码做的每一次修改——比反复按 Ctrl+S 可靠得多。在终端中输入以下命令检查 Git 是否已安装：

git --version

如果尚未安装，请前往 Git 官方下载页按操作系统安装包完成安装。

2.2 首次设置用户身份

安装后，需要向 Git 介绍“你是谁”。这条信息会被附加到每一次 commit 上，因此请选择你愿意公开分享的名字与邮箱：

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

--global 表示该配置对所有仓库生效；检查当前全部配置用：

git config --list

2.3 账户、编辑器与终端

• GitHub 账户：在 GitHub 官网注册或登录，并完善个人资料（头像、简介等）；
• 代码编辑器：推荐 Visual Studio Code；
• 终端：macOS/Linux 用 Terminal，Windows 用命令提示符或 PowerShell。

💡 小知识（课程原话核对）：GitHub 并非世界上唯一的代码托管平台，但它是知名度最高的一个。

2.4 安全第一：现代认证与账户保护

课程用“锁车、锁门”来类比 GitHub 安全习惯，主张从第一天就养成现代化安全实践，核心原则如下表：

安全领域	最佳实践	为什么重要
认证（Authentication）	使用 SSH 密钥或 Personal Access Token（个人访问令牌）	密码更不安全且正被逐步淘汰
双因素认证（2FA）	在 GitHub 账户中启用 2FA	为账户增加额外一层保护
仓库安全	绝不提交敏感信息	API Key 与密码永远不应出现在公开仓库
依赖管理	启用 Dependabot 自动更新	保持依赖安全且处于最新版本

⚠️ 关键安全提醒：绝不把 API Key、密码等敏感数据提交进任何仓库。应使用环境变量（environment variables）与 .gitignore 文件保护机密信息。

现代 SSH 认证配置示例（ed25519 是当前推荐的现代算法）：

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

# 让 Git 改用 SSH 方式访问远端
git remote set-url origin [e-mail]:username/repository.git

💡 专业建议：SSH 密钥省去反复输入密码的麻烦，比传统口令认证更安全，是“免密推送”的基础。

补充说明：除 SSH 外，也可以使用 HTTPS + Personal Access Token，或直接使用 GitHub CLI（gh）完成认证。课程还提供了 gh 的现代快捷路径（见下文 3.7）。

准备动作：你需要同时拥有“本机（笔记本或台式机）上一个含代码的项目文件夹”和“GitHub 上的一个公开仓库”，后者将作为后续学习“如何为他人项目做贡献”的演练对象。

---

三、像专业人士一样管理代码：创建第一个仓库

3.1 Git 工作流全景

将文件夹交给 Git 后，它就像一本“会时间旅行的笔记本”：记住每一次键入、每一处改动，也让你可以瞬间撤销“哦不，我把一切搞坏了”的时刻。阅读自己几天、几周甚至几个月前写下的 commit message，能帮你回忆起当时的决策理由，并在必要时“回滚”变更——前提是 commit message 写得足够好。

一次典型的 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 与克隆]
    I -->|否| D
    J --> K[创建分支]
    K --> L[做修改]
    L --> M[Pull Request]
    M --> N[🎉 完成贡献!]

3.2 第一步：在 GitHub 上创建仓库

登录 GitHub.com，点击右上角的绿色 New 按钮（或 + 号），选择 New repository，然后：

1. 为仓库命名（取一个对你有意义的名字）；
2. 按需填写描述（帮助他人理解项目内容）；
3. 决定公开（Public，人人可见）或私有（Private，仅自己可见）；
4. 建议勾选自动生成 README 文件——它是项目的主页；
5. 点击 Create repository 完成创建。

3.3 进入项目目录并初始化

# 进入你的项目文件夹（替换成真实文件夹名）
cd [name of your folder]

随后把普通文件夹“升级”为 Git 仓库：

git init

这一步发生了什么：Git 在项目内创建了一个隐藏的 .git 目录（你看不到它，但它真实存在）；你的文件夹从此变成“仓库”，能够跟踪之后每一次修改——相当于给文件夹赋予了“记住一切”的超能力。

3.4 用 git status 随时掌握状态

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 会友好地提示你接下来可以做什么。

💡 专业建议：git status 是你最好的朋友。任何时候搞不清状态，就执行它——相当于问 Git“现在到底是什么情况？”（它同样能显示当前位于哪个分支，见 3.8）。

3.5 暂存（Staging）：用 git add 挑选要保存的内容

# 把所有文件加入下一次提交
git add .

# 只加入特定文件或目录
git add [file or folder name]

点号 . 表示“本目录下的一切”。为何要“选择性暂存”？——当你想把彼此关联的改动成组保存、把工作拆成逻辑清晰的单元、让“何时改了什么”一目了然时，精确的 git add 就很有用。

改主意了？ 取消暂存并不会删除你的工作，只是把文件移出“待保存”队列：

# 取消暂存全部
git reset

# 取消暂存单个文件
git reset [file name]

3.6 提交：创建项目历史上的第一个快照

git commit -m "first commit"

发生的事：Git 为此刻所有已暂存文件拍下一张“快照”；-m 后的消息“first commit”解释了这个保存点的含义；Git 还给快照分配了唯一 ID，以便日后查找。从此你正式开始了项目历史追踪。

💡 后续提交请写得更具描述性：与其写 “updated stuff”，不如写“在首页添加联系表单”或“修复导航菜单的 Bug”。未来的你会感谢现在的你。

3.7 连接本地与 GitHub 远程仓库

此刻项目只存在于本地电脑。回到 GitHub 仓库页面复制仓库 URL，然后执行：

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

（务必替换为你的真实仓库 URL。）

要点：origin 只是你 GitHub 仓库的“昵称”（类似给手机通讯录加联系人）；现在本地 Git 知道了未来要把代码发往哪里。

更省事的做法——如果装有 GitHub CLI，一条命令即可完成“创建远程仓库 + 推送”：

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

3.8 推送：把代码送上 GitHub

git push -u origin main

• -u 建立“上游”持久关联，让以后的推送更省事；
• main 是主分支名（相当于“主目录”）；
• 之后只需 git push 即可完成后续上传。

💡 若你的分支叫 master 等其他名字，请换成实际名称；可用 git branch --show-current 查看当前分支名。

3.9 你的日常编码节奏

从此以后，每次改动只需三步循环：

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

这套节奏如同游戏的存档点：做了喜欢的改动就提交；想尝试高风险实验也无需害怕——搞砸了随时可回到上一个 commit。还可以用 .gitignore 防止不想被跟踪的文件（如放在同目录的私人笔记）被推上 GitHub，官方维护了大量模板可直接参考选用。

3.10 状态机视角理解三个命令

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

复盘自测：第一次在 GitHub 看到自己代码的感受？哪一步最困惑、哪一步意外地简单？能否用自己的话解释 git add、git commit、git push 的差异？（别忘了：熟练开发者也常记不住精确命令，把它练成肌肉记忆就好。）

---

四、Commit Message 与现代 Git 工作流

4.1 一条好 Commit Message 的检验标准

一个优秀的 commit 主题行，应当能自然补全下面这句话：

如果应用此提交，它将会 <你的主题行>

主题行请使用命令式、现在时：写 “change”，而不是 “changed” 或 “changes”。正文（可选）同样使用命令式现在时，并说明变更的动机、与先前行为的对比——解释“为什么”（why），而不是“怎么做”（how）。

4.2 推荐采纳的现代实践

• Conventional Commits（约定式提交）：使用标准化消息前缀，如 feat:（新功能）、fix:（修复）、docs:（文档）等，便于自动生成 changelog 与语义化版本；
• 原子化提交（Atomic commits）：让每个 commit 只代表一个逻辑上的单一变更；
• 频繁提交（Frequent commits）：勤提交、消息描述清楚，而不是攒成一次“大而稀”的提交。

✅ 实践练习：花几分钟逛逛 GitHub，找一个真正出色的 commit message，再找一个极其简短的；思考你最希望在提交信息里读到哪些信息。同时，试试去 .github/pull_request_template.md 这类模板文件——本仓库就内置了 PR 模板，提示贡献者在描述中说明“变更摘要与关联 issue（Fixes # …）”及变更类型。

---

五、与他人协作（Fork 与 Pull Request 工作流）

5.1 为什么“上传到 GitHub”是为了协作

把代码放到 GitHub 的首要目的就是让协作成为可能。把代码放到 GitHub 上的根本原因，就是让它具备与他人的协作能力。

一次完整的贡献协作链：

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

5.2 用 Insights > Community 检查仓库健康度

想让仓库看起来专业又友好？进入仓库页面点击 Insights > Community。这个功能会展示你的项目与 GitHub 社区认可的“好仓库实践”之间的差距。

🎯 一个文档完备、组织良好的仓库，就像整洁迎客的临街店铺——它告诉别人你在乎自己的工作，也让别人更愿意参与贡献。

5.3 好仓库的标准配置清单

应添加的内容	为什么重要	能带来什么
Description（项目描述）	第一印象至关重要	人们立刻知道项目做什么
README	项目的主页	像新访客的友好导游
Contributing Guidelines（贡献指南）	表明你欢迎帮助	人们知道具体如何参与
Code of Conduct（行为准则）	营造友好空间	每个人都感到受欢迎
License（许可证）	法律上的清晰界定	他人知道如何使用你的代码
Security Policy（安全策略）	展示责任感	体现专业实践

💡 GitHub 为以上所有文件都提供了模板；创建新仓库时，勾选对应选项即可自动生成。

仓库实例佐证：这个 Web-Dev-For-Beginners 仓库本身就是“标准配置”的样板——根目录下存放着 README.md（含使用说明、克隆方式与课程地图）、CONTRIBUTING.md（说明贡献者需同意 CLA 及提交 PR 的规范）、CODE_OF_CONDUCT.md、SECURITY.md 与 LICENSE；.github/pull_request_template.md 为所有 PR 提供统一描述模板，.github/ISSUE_TEMPLATE 目录下提供 Bug 报告与功能请求模板，.github/workflows 目录下的 stale.yml、links.yml 等则是 GitHub Actions 自动化的实际落地。从源码结构看，这正对应上表“描述 + README + 贡献指南 + 行为准则 + 许可证 + 安全策略”的完整实践。

5.4 探索现代 GitHub 功能

🤖 自动化与 CI/CD：

• GitHub Actions：自动化测试与部署；
• Dependabot：自动更新依赖。

💬 社区与项目管理：

• GitHub Discussions：议题之外更轻松的社区讨论；
• GitHub Projects：看板（Kanban）风格项目管理；
• Branch protection rules（分支保护规则）：强制执行代码质量标准。

这些资源能显著降低新成员的上手成本，也是新贡献者“看代码之前”最先考察的维度——他们据此判断这个项目是否值得投入时间。

✅ 拓展任务：去看看本仓库的 README、模板与 workflow 文件；README 等文档虽然耗时，却常被忙碌的维护者忽略。你还能在 docs/_navbar.md、docs/_sidebar.md 等文件中看到文档站导航的组织方式。

5.5 任务：合并代码——完整的贡献者工作流

先厘清四个概念：Fork（在贡献者的 GitHub 账号下生成你仓库的副本）→ Clone（把项目克隆到贡献者本地）→ Branch（为他们的工作创建分支）→ 聚焦单一改动（一次只集中在一处变更，合并成功率才会高；试想某人同时修 Bug、加功能、改测试，而你只想/只能合并其中 1/3）。

✅ 思考：设想“分支”对写出、发布优质代码至关重要的场景——你能举出哪些用例？（提示：功能分支、Bug 修复分支、实验性改动。任何 commit 都会落在你当前“检出的分支”上，用 git status 查看当前分支。）

假设贡献者已完成 Fork 与 Clone，在本地拥有一个可工作的 Git 仓库，接下来按序执行：

① 创建分支

git branch [branch-name]

💡 现代做法：一条命令同时创建并切换到新分支：

git switch -c [branch-name]

② 切换到工作分支

git switch [branch-name]

💡 git switch 是 git checkout 在“切换分支”场景下的现代替代品，语义更清晰、对初学者更安全。

③ 提交你的改动

git add .
git commit -m "my changes"

⚠️ 无论为了自己还是被帮助仓库的维护者，务必给 commit 起个好名字，具体说明改了什么。

④ 与 main 分支合并，把冲突留在自己的工作分支

main 在你工作期间可能已经前进，先把它更新到最新：

git switch main
git pull

然后回到自己的分支执行合并，这样任何 冲突（Git 无法自动合并的场景）都发生在你的工作分支上：

git switch [branch_name]
git merge main

git merge main 会把 main 上的全部变更并入你的分支。顺利的话直接继续即可；若不顺利，VS Code 等编辑器会标出 Git “困惑”的位置，你只需编辑受影响的文件、决定哪部分内容最准确。

💡 现代替代方案：追求更干净的历史可用 git rebase：

git rebase main

它把你的提交“重放”到最新的 main 之上，形成线性历史。（merge 保留真实合并节点，rebase 让历史更线性——初学者可先掌握 merge，再进阶到 rebase。）

⑤ 推送到 GitHub 并创建 PR

“把工作发送到 GitHub”包含两件事：把分支推到自己的（Fork 出的）远程仓库，然后发起 Pull Request：

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

上面的命令会在你的 Fork 仓库中创建该分支。

5.6 打开 Pull Request

进入你在 GitHub 上 Fork 的仓库，GitHub 会提示是否创建新 PR；点击后进入界面，可改写 PR 标题、补充更贴切的描述。随后，被你 Fork 的原仓库维护者将看到这个 PR——祈祷他们会认可并 merge 你的 PR。此刻你就正式成为一名贡献者了 🎉。

💡 用 GitHub CLI 也能创建 PR：

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

🔧 PR 最佳实践：

• 用关键词关联相关 issue，例如 “Fixes #123”；
• UI 改动附上截图；
• 指定具体评审人（reviewers）；
• 未完成的半成品用 draft PR（草稿 PR）；
• 请求评审前，确保所有 CI 检查都已通过。

5.7 合并后的清理

PR 成功合并后，好习惯是把本地分支和已推送的远端分支都清理掉：

git branch -d [branch-name]

然后到 GitHub 上 Fork 仓库的页面，删除刚推送的远端分支。

5.8 理解“Pull Request”这个名字

“Pull request”听起来奇怪——你明明是想“推送”改动。但真正的流程是：维护者（项目所有者）或核心团队需要先审阅你的变更，再决定是否并入项目 main 分支。所以你其实是在向维护者“请求一个变更决策”。

PR 是“比较与讨论分支改动差异”的场所：支持评审、评论、集成测试等。一个好的 PR 遵循与 commit message 大致相同的规则。需要关联 issue 时，用 # 加 issue 编号即可，例如 #97——在 .github/pull_request_template.md 中也能看到 “Fixes # (issue)” 的占位约定。

🤞 祈祷所有检查通过、项目所有者合并你的变更 🤞

平时保持本地与远程同步：

git pull

---

六、参与开源：把代码“复制”到本地的四种方式

6.1 从 good first issue 开始

多数开源项目欢迎新人，并专门提供标注 “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[📝 写清晰的 commit]
    I --> J[📤 推送并创建 PR]
    J --> K[💬 回应反馈]
    K --> L[🎉 被合并! 你已是贡献者!]
    L --> M[🌟 寻找下一个 issue]

6.2 克隆仓库：HTTPS / SSH / GitHub CLI

先在 GitHub 上找到一个你感兴趣、想为之做贡献的仓库（repo），然后把它的内容“复制”到本机。克隆（clone）可通过 HTTPS、SSH 或 GitHub CLI 完成：

# 使用 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

6.3 更多打开项目的方式

除命令行克隆外，还可以：

• GitHub Codespaces：GitHub 的云端开发环境，浏览器内直接使用 VS Code；
• GitHub Desktop：面向 Git 操作的图形化桌面应用；
• GitHub.dev：在任意 GitHub 仓库页面按下 . 键，即可在浏览器中打开 VS Code；
• VS Code + GitHub Pull Requests 扩展：直接在编辑器内完成审阅与协作；
• 最后，也可以直接把代码下载为 ZIP 压缩包。

✅ 试试：逛逛你的新 GitHub 仓库并动手尝试——编辑设置、补充仓库信息、创建 Projects（Kanban 看板）、配置 GitHub Actions 自动化。可以做的事情非常多。

6.4 有趣的小功能与项目交互

• 你可以在 GitHub 上对任意公开仓库 star（加星）、watch（关注）、fork；加星记录位于右上角下拉菜单，相当于“针对代码的书签”；
• 项目通常有 issue 跟踪器（默认在 “Issues” 标签页），供人们讨论与项目相关的问题；Pull Requests 标签页则是讨论与评审进行中改动的地方；
• 项目也可能在论坛、邮件列表或 Slack/Discord/IRC 等聊天频道中开展讨论。

🔧 现代 GitHub 功能一览：

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

---

七、挑战与巩固：把技能变成习惯

7.1 双人挑战

邀请一位朋友（或总在问“你到底在用电脑做什么”的家人）一起开启协作编程冒险：创建项目 → 让对方 Fork → 各自建分支 → 像专业人士一样合并改动。你们很可能在“同时改同一行”时笑场，也可能困惑抓头，但一定会收获让学习值得的“Aha!”时刻。没有结对伙伴？没关系——去寻找带 “good first issue” 标签的仓库，GitHub 社区对新人非常友好。

7.2 GitHub Copilot Agent 模式挑战（本课新增）

使用 Copilot 的 Agent 模式完成：新建一个公开仓库，主题为“Web 开发资源”项目，README 需按 HTML/CSS/JavaScript 等分类列出实用资源；按社区标准配置许可证、贡献指南与行为准则；创建两个功能分支（一个加 CSS 资源、一个加 JavaScript 资源）；为每个分支写描述性提交；随后创建 PR 把改动合并回 main；最后启用 Issues、Discussions 并配置一个基础的 GitHub Actions 工作流用于自动化检查。整个过程恰好复现本课全部知识点。

7.3 课后作业与进阶方向

• 完成 GitHub Skills 平台的 “Introduction to GitHub” 交互式课程（安全、有指导的练习环境，完成后可获得徽章）；
• 配置 SSH 认证，实现真正“免密”操作；
• 用 GitHub CLI 处理日常 Git 操作；
• 创建一个带 GitHub Actions 工作流的仓库；
• 尝试用 Codespaces 云端环境打开并编辑这个课程仓库。

7.4 GitHub 精通时间线（速查清单）

周期	可执行动作
5 分钟	给本仓库及其他 3 个感兴趣的项目加星；开启账户 2FA；为第一个仓库写简单 README；关注 5 位作品启发你的开发者
1 小时	完成课后测验并复盘；配置 SSH 免密认证；写出第一条“好 message”的 commit；浏览 GitHub Explore 发现流行项目；练习 Fork 一个小改动
一周	完成 GitHub Skills 基础课（Introduction to GitHub、Markdown）；向开源项目提交第一个 PR；用 GitHub Pages 搭建展示站；参与项目 Discussions；为仓库配齐社区标准文件；体验 Codespaces
一个月	向 3 个不同开源项目做贡献；指导一位 GitHub 新人；用 GitHub Actions 建立自动化工作流；打造展示个人贡献的作品集；参与 Hacktoberfest 等社区活动；成为“被他人贡献”的项目维护者

---

八、总结回顾

Git 与 GitHub 非常强大，而每个“看起来像魔法师”的开发者都曾跌倒练习。能读到本课结尾，说明你已走在上手开发者工具箱中最重要工具的途中。GitHub 官方还提供一系列交互式技能课程用于安全练习，包括：Introduction to GitHub（入门）、用 Markdown 沟通、GitHub Pages（个人站点）、处理合并冲突等；此外 GitHub CLI、Codespaces、Actions 的官方文档，以及 Git 最佳实践教程，都值得在进阶时阅读。

🌍 欢迎来到全球开发者社区：你已拥有与世界数百万开发者协作的工具。你的第一次贡献或许很小，但请记住——每个大型开源项目都始于某人敲下的第一次 commit。问题从来不是“你能否产生影响”，而是“哪个优秀的项目会最先受益于你独特的视角”。每个专家都曾是从零开始的新手，你一定可以 💪。

---

本文基于 Web-Dev-For-Beginners 课程的保加利亚语译本 translations/bg/1-getting-started-lessons/2-github-basics/README.md 整理撰写，内容与英文原版 1-getting-started-lessons/2-github-basics/README.md 保持一致；Git/GitHub 相关命令与概念以对应课程文档及本仓库源码结构为准。