从零入门 GitHub：基于 Web-Dev-For-Beginners 的版本控制与开源协作全流程实战指南

2026-09-07 18:27:36作者：韦蓉瑛

本篇技术指南以 Web-Dev-For-Beginners 前端入门课程中「Getting Started」模块的第 2 课 Introduction to GitHub 为核心主体，系统讲解在真实 Web 开发学习中会用到的最低必要 GitHub 技能栈：从 Git 环境安装与身份配置、仓库安全实践，到「本地提交—远端推送」的日常循环，再到 Fork/分支/Pull Request 协作流程与开源贡献方法论。读完本文你将能够独立完成"创建第一个仓库 → 持续提交代码 → 以贡献者身份给他人项目合入代码"的完整闭环，并理解 GitHub 社区标准（README、License、贡献指南等）对一个项目可维护性与可协作性的意义。

本文依据的源文档位于仓库内 translations/ar/1-getting-started-lessons/2-github-basics/README.md（阿拉伯语版，对应英文原版 Introduction to GitHub）。本课位于课程目录 Getting Started with Web Development 三个非项目型基础主题（编程语言与工具、GitHub 入门、无障碍基础）中的第 2 节，属于学习者进入动手项目前的"工具准备"环节。

先建立两个核心概念：Git 与 GitHub

在敲下第一条命令之前，先分清两个经常被混用的概念：

Git 是一个版本控制系统（Version Control System）。它在你本地的项目目录里默默记录每一次代码改动，相当于一本"可以穿越时间的笔记"——你能回溯任意一次修改，也能在写坏代码后"读档"回到上一个安全点。它完全在本地工作，不依赖任何网站。
GitHub 是构建在 Git 之上的协作平台。你可以把它理解为"程序员的社交网络"：把本地的 Git 仓库推送到 GitHub 上，与全世界的开发者共享、讨论并一起改进代码。它不是世界上唯一的代码托管服务，但它是目前知名度最高的一个。

本课设定的学习路径非常清晰：先学会在本地用 Git 跟踪自己的工作 → 再学会把项目推到 GitHub 与别人协作 → 最后尝试参与开源。整个过程会依次经历三个阶段的能力跃迁：

阶段	核心动作	熟练标志
环境搭建	安装 Git、注册账号	能通过 `git --version` 与 `git config --list` 确认环境就绪
驾驭 Git	`init`、`add`、`commit`、`push`、`branch`	形成"改动—提交—推送"的肌肉记忆
参与协作	Fork、Clone、PR	能向他人仓库提交一次被合入的贡献

环境准备：安装并配置 Git

所有操作的第一步，是让本地计算机具备"版本管理能力"。整个过程只需一次性配置，之后将长期受用。

检查并安装 Git

在终端里输入以下命令，确认 Git 是否已经存在：

git --version

若能看到版本号输出，说明 Git 已安装，可以直接进入配置环节；
若提示命令不存在，则需先从 Git 官方网站下载对应操作系统的安装包并完成安装，之后再次验证。

首次配置：告诉 Git"你是谁"

Git 会把每一次提交（commit）都附带提交者的身份信息，因此首次安装后必须完成身份声明。请选择你愿意公开分享的姓名与邮箱——它们将出现在你未来所有公开提交的历史中：

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

--global 表示该配置作用于当前系统用户下的所有仓库，只需设置一次。设置完成后，可随时用以下命令查看当前生效的全部 Git 配置，确认是否设置成功：

git config --list

还需要准备的三样东西

一个 GitHub 账号：前往 github.com 注册；如果已有账号，登录并完善个人资料。它是后续所有云上操作的身份凭证。
一个代码编辑器：本课推荐 Visual Studio Code（VS Code）。课程的英文原版教程中多次提到 VS Code 在合并冲突场景下的可视化提示能力，后文会详细说明。
一个终端：在 Windows 上是命令提示符/PowerShell，在 macOS/Linux 上是 Terminal。后续所有 git 命令都在其中执行。

💡 面向现代的认证建议：可以提前考虑配置 SSH 密钥或安装 GitHub CLI，二者都能避免频繁输入密码的麻烦。具体做法见下一节"安全实践"。

保持代码安全：从一开始就养成现代安全习惯

很多初学者把安全放在"以后再说"，但本课强调：正确的工作习惯应该从第一天建立。把这些实践想象成"出门锁车锁门"式的默认动作即可，它们不复杂，却能保护你长期积累的成果。

四个安全关注领域的标准做法

安全领域	最佳实践	为什么重要
身份认证	使用 SSH 密钥或个人访问令牌（Personal Access Tokens）	密码安全性较弱，且正在被平台逐步淘汰
双因素认证	在 GitHub 账号上启用 2FA	为账号增加一层额外的保护
仓库安全	绝不把敏感信息提交进仓库	API 密钥、密码等永远不应出现在公开仓库中
依赖管理	启用 Dependabot 自动更新	让项目依赖保持安全与最新

⚠️ 关键安全提醒：永远不要把 API 密钥、密码或任何敏感信息提交到任何仓库。敏感数据应通过环境变量与 .gitignore 文件保护——后者可以指定一批"不被 Git 跟踪"的文件，例如你存放在项目文件夹里、但不该进入公开仓库的个人笔记文件。

现代认证方式的落地命令

SSH 密钥能够消除反复输入密码的需要，同时比传统密码认证更安全。生成密钥并切换远端地址的操作如下：

# 生成 SSH 密钥（推荐现代的 ed25519 算法）
ssh-keygen -t ed25519 -C "your_email@example.com"

# 将本仓库的远端地址切换为 SSH 形式
git remote set-url origin git@github.com:username/repository.git

ed25519 是当前公认安全且高效的签名算法；-C 后的注释通常写邮箱，便于日后识别这把密钥的归属。生成后按提示将公钥添加到 GitHub 账号的 SSH Keys 设置中即可。

实战任务一：创建并发布你的第一个仓库

这一节是本课的"核心主线任务"：在 GitHub 上创建第一个仓库，并把本地代码通过 Git 发布上去。完成它，你就正式迈入了全球开发者协作的圈子。

第 1 步：在 GitHub 网页端创建空仓库

登录 GitHub，点击右上角的 New 按钮（或 + 号）并选择 New repository；
为仓库命名——建议取一个有意义的名称；
视需要填写描述（Description），帮助他人快速理解项目用途；
选择可见性：Public（所有人可见）或 Private（仅自己可见）；
建议勾选 Add a README file——README 相当于项目的"门面首页"；
点击 Create repository 完成创建。

说明：也可以在 GitHub 创建页直接生成 LICENSE、.gitignore 等配套文件；GitHub 为这些社区标准文件都提供了现成模板，勾选即可自动生成。

第 2 步：进入本地项目目录

在终端中切换到存放代码项目的文件夹：

cd [name of your folder]

把 [name of your folder] 替换成你真实的项目目录名。cd 的作用是告诉系统"我要把工作环境切换到哪个文件夹"，与双击桌面文件夹打开它是一回事，只是改用了文本命令。

第 3 步：把普通文件夹升级为 Git 仓库

git init

这条命令会在项目内创建一个隐藏的 .git 文件夹（平时不可见，但确实存在）。从这一刻起，你的文件夹就变成了一个能够跟踪每一次改动的"仓库"，拥有记住一切的能力。

第 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 add 后）表示"已就绪，可被保存"；
每条提示下方 Git 都会贴心地给出下一步可用命令。

第 5 步：暂存（Staging）你的改动

git add .

这里的 . 表示"本文件夹内的全部内容"。执行后，所有改动都会进入"暂存区"，处于待提交状态。

如果希望更精细地控制，可以只添加指定的文件或目录：

git add [file or folder name]

这样做的价值在于：把彼此相关的改动分组暂存、分别提交，从而让提交历史更清晰、更易理解。

如果暂存后又改变主意，可以用 git reset 撤销暂存（注意：这不会删除你的工作成果，只是把文件移出"待提交"队列）：

# 撤销全部暂存
git reset

# 只撤销某一个文件
git reset [file name]

第 6 步：用 commit 永久保存（第一次提交！）

git commit -m "first commit"

这条命令完成后你将拥有第一个提交。它的工作原理是：

Git 在当前时刻为所有已暂存文件拍下一张"快照"；
-m 后面的消息 first commit 说明了本次保存的内容；
Git 为该快照分配唯一 ID，确保未来任何时候都能定位到它；
项目的历史追踪就此正式开启。

💡 提交消息建议：从第二次提交开始，请让消息更具描述性。不要写 updated stuff，而应写 Add contact form to homepage 或 Fix navigation menu bug。未来的你（以及协作者）会因此受益。

第 7 步：把本地仓库与 GitHub 仓库关联

此时你的代码还只存在于本地。先在 GitHub 仓库页面复制该仓库的 URL，然后执行：

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

请将 URL 替换为你的真实仓库地址。这条命令的含义：

在本地与远端 GitHub 仓库之间建立一条连接；
origin 只是这个远端仓库的"别名/昵称"（相当于给联系人存的备注名）；
此后本地 Git 就知道"该把代码发往哪里"了。

更省事的替代方案：如果安装了 GitHub CLI，一行命令即可完成"创建远程仓库 + 关联 + 推送"：

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

第 8 步：把代码推送到 GitHub（高光时刻！）

git push -u origin main

这一步把你的提交从本地传输到 GitHub。关键参数说明：

-u（即 --set-upstream）会建立本地分支与远端分支的长期关联，此后只需输入 git push 即可完成推送；
main 是你的默认主分支名（可以理解为主干线/主文件夹）；
若你的默认分支叫 master（较老项目或旧版 Git 初始化默认值），请改用该名称。可用 git branch --show-current 查看当前所在分支名。

第 9 步：形成你的日常编码节奏

从今往后，每次改动代码都只需重复三连命令，它们会成为你编程的"心跳"：

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

这套工作流的本质逻辑是——做出改动 → git add 暂存 → git commit 快照存档 → git push 同步云端，循环往复。它的好处正如游戏中的多存档点：改动满意就立刻保存；想尝试风险操作也毫无压力，出了问题随时可以回退到上一个提交。

提交流程可视化

把上面 9 个步骤压缩成一张状态流转图，可以更直观地理解 Git 的四个工作区：

创建/修改文件（工作区）
      │
      ▼
git add .  ──► 暂存区（Staged：文件已就绪待保存）
      │
      ▼
git commit ──► 本地提交（Committed：已生成不可变的快照）
      │
      ▼
git push  ──► GitHub 远端仓库（发布成功）

工程化的提交习惯：Commit Message 规范

一次"合格"的提交，远不止"能保存代码"。本课专门强调了专业团队通行的提交规范，值得尽早内化：

现代 Git 工作流三原则

约定式提交（Conventional Commits）：为提交消息采用统一的前缀格式，如 feat:（新功能）、fix:（修复）、docs:（文档）等，使提交历史可以被机器化地归类与筛选；
原子提交（Atomic Commits）：让每一次提交只代表一个单一的逻辑改动，避免把无关修改混在一次提交里；
频繁提交（Frequent Commits）：与其攒一个巨大的提交，不如用带有描述性消息的小提交更频繁地记录进度。

写好提交主题行的方法论

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

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

例如"If applied, this commit will add login form validation"——如果你写不出能让句子通顺的主题，说明这条提交的意图还不够聚焦。

在语态上，主题行应使用祈使句、一般现在时：写 change，而不是 changed 或 changes。可选的正文（body）也应保持同一语态。正文重点应放在解释**"为什么做这次改动"（动机）以及与旧行为的对比**，而不是罗列"怎么改"（代码细节自己会说话）。换言之：你解释的是 why，不是 how。

自检练习：花几分钟在 GitHub 上浏览公开项目，试着找出一条"非常出色的提交消息"和一条"过于简陋的提交消息"，思考哪类信息对读者最有价值——这正是提升提交质量的捷径。

让仓库"欢迎贡献"：社区标准与项目门面

GitHub 的核心价值是协作，而高质量协作的前提是仓库本身容易被理解、容易上手。本课建议你前往自己仓库的 Insights > Community 页面，查看项目与 GitHub 社区公认的"优秀仓库实践标准"的差距。一个组织良好、文档齐全的仓库，就像一家整洁亮眼的实体店门面——它传达"作者认真对待这个项目"的信号，也让其他人愿意投入时间参与贡献。

优秀仓库必备的六样东西

应添加的内容	为什么重要	能带来什么
项目描述（Description）	第一印象决定一切	人们瞬间明白你的项目是做什么的
README	项目的首页	像贴心的导游手册，引导新访客快速上手
贡献指南（Contributing Guidelines）	表明你欢迎帮助	人们确切知道该如何协助你
行为准则（Code of Conduct）	营造友好的空间	让每个人都感到被欢迎、愿意参与
开源许可证（License）	法律层面的清晰	他人知道能以何种方式使用你的代码
安全策略（Security Policy）	体现作者的责任心	展示专业的维护实践

一个可验证的仓库范例就在本文所在仓库本身：仓库根目录下就存放着这些社区标准文件——CODE_OF_CONDUCT.md、CONTRIBUTING.md、LICENSE、SECURITY.md、SUPPORT.md。这正是一个"想让陌生贡献者放心参与"的项目应当具备的完整配置，也说明该课程仓库本身就是本课所讲规范的实践样本。此外，仓库还维护了 50+ 语言的翻译版本，例如本文所依据的阿拉伯语课程文档，这同样依赖贡献者通过后续要讲的 PR 流程持续协作维护。

💡 专业提示：GitHub 为上述所有文件都提供模板。新建仓库时，在创建界面勾选对应选项即可自动生成，无需从零撰写。

这类"社区基建"的价值不仅在于好看——新贡献者往往在阅读你的代码之前，先通过这些文件判断项目是否值得投入时间；它们也会显著降低新成员加入团队后的上手成本。

现代 GitHub 协作功能速览

本课还梳理了一组面向协作与项目治理的现代功能，值得在完成基础流程后逐步探索：

🤖 自动化与 CI/CD：GitHub Actions（自动化测试与部署）、Dependabot（自动更新依赖并保持安全）；
💬 社区与项目管理：GitHub Discussions（issue 之外的社区讨论区）、GitHub Projects（看板式项目管理）、分支保护规则（强制代码质量标准，例如要求 PR 评审通过后才能合入主分支）。

实战任务二：以贡献者身份完成一次协作合并

主仓库主人在 GitHub 上的常见诉求是"让别人能把代码合入我的项目"。为此，本课设计了第二个核心任务，围绕一个完整的外部贡献者（Contributor）工作流展开。请先理解协作链路的四个关键环节：

Fork（派生/复刻）：贡献者在自己的 GitHub 账号下创建仓库副本。Fork 意味着把仓库"复制"到自己的个人空间；
Clone（克隆）：把 Fork 得到的仓库下载到本地机器；
Create a branch（创建分支）：要求贡献者在独立的分支上开展工作；
聚焦单一改动：要求每次贡献集中于一个主题。原因很实际——如果贡献者同时提交了一个 bug 修复、一个新功能加若干测试更新，而维护者只想/只能合入其中的一部分，拆分困难会大大降低合并成功率。

提示：请你也"成为你想在世界上看到的改变"——为自己本地的工作同样创建分支。所有提交都会落在当前"已检出（checked out）"的分支上，用 git status 可随时确认当前所在分支。

下面假设贡献者已完成 Fork 与 Clone，本地已有一个可直接开工的 Git 仓库，逐步走完贡献流程：

步骤 A：创建并切换到工作分支

git branch [branch-name]

创建一个承载待贡献改动的新分支。更现代的写法是创建与切换一步到位：

git switch -c [branch-name]

git switch 是取代旧版 git checkout 的新命令，专门用于分支切换，语义更清晰、对初学者更安全。若分支已存在，仅需切换：

git switch [branch-name]

步骤 B：提交你的改动

在分支上完成编码后，暂存并提交：

git add .
git commit -m "my changes"

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

步骤 C：把主分支的最新内容合入你的分支

当工作完成、准备把成果并入 main 时，需要注意 main 可能已在你工作期间被他人更新。因此先切回主分支并拉取最新内容：

git switch main
git pull

再切回你的工作分支，把主分支合并进来：

git switch [branch_name]
git merge main

git merge main 会把 main 上的全部新提交带进你的分支。顺利的话直接继续即可；若产生合并冲突（Git 无法自动合并的改动），VS Code 会以可视化方式标出 Git "困惑"的位置——此时只需手动编辑受影响文件，选定保留哪个版本的内容即可。冲突解决本质上是"告诉 Git 哪个内容是对的"，不必畏惧。

💡 现代化替代：追求更干净的历史时可用 git rebase main 替代 merge。它会把你的提交"重放"到最新的 main 之上，从而形成线性的提交历史（更利于审查与回溯）。

步骤 D：推送到远端并发起 Pull Request

把工作成果送达 GitHub 包含两件事：推送分支 与 发起 Pull Request（PR）。推送命令：

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

--set-upstream 会在你的 Fork 远端仓库上创建同名分支并建立关联。之后前往 GitHub 上的 Fork 仓库页面，页面会出现创建新 PR 的提示，点击进入 PR 编辑界面——在那里可以修正提交标题、补写更合适的描述。随后，被 Fork 的原始仓库维护者会看到你的 PR，若认可便会 merge（合并） 它，你便正式成为该项目的贡献者。

补充：PR 的本质与最佳实践

为什么叫"Pull Request"（拉取请求）？ 这个术语初看有些反直觉——你明明是想把自己的改动推进项目。原因在于：改动是否进入主分支的决定权在项目所有者（维护者）或核心团队手中。他们需要先审查你的改动，再决定是否合入 main，所以本质上你是向维护者请求一次关于改动的裁决。

PR 是"对某个分支引入的差异进行比较与讨论"的空间：支持代码评审、评论、内置测试等。一份优秀 PR 的撰写规则与优秀提交消息大致相同，还可以在描述中引用关联 Issue——写法是在 Issue 编号前加 #，例如 Fixes #97 表示本 PR 解决了第 97 号 Issue。

用 GitHub CLI 创建 PR 的命令：

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

PR 最佳实践清单：

用 Fixes #123 之类的关键词关联相关 Issue；
UI 改动要附带截图；
指定具体的评审人（reviewers）；
进行中的工作可使用草稿 PR（draft PR）；
在请求评审前，确保所有 CI 检查全部通过。

步骤 E：合并后的清理工作

PR 成功合并后，业界惯例是清理善后：既清理本地分支，也清理已推到 GitHub 的远端分支。先删除本地分支：

git branch -d [branch-name]

然后前往 GitHub 上 Fork 仓库的页面，删除对应的远端分支。最后，用 git pull 把当前本地分支更新为远端对应的最新提交，与社区进度保持同步：

git pull

上述完整协作链路可用一句话概括：Fork → Clone → 创建分支 → 聚焦式改动 → 与 main 对齐（merge/rebase）→ 推送分支 → 发起 PR → 处理评审反馈 → 合并 → 清理分支。这正是现代开源团队每天都在运行的标准流程。

参与开源：找到并完成你的第一次外部贡献

学会在自己/他人的仓库上协作之后，下一步是真正投身开源世界——修复你日常所用工具的一个 bug，或为某个框架添加功能。每一款你正在使用的编辑器、框架甚至浏览器，最初都始于某个人的第一次贡献；而开源社区对新人普遍极其友好，多数项目专门维护着标记为 good first issue 的入门级 Issue 来欢迎新手。

克隆开源仓库的三种方式

选定目标仓库后，第一步是把它复制到本地。终端中的克隆命令有三种协议变体：

# 方式一：HTTPS（无需额外配置）
git clone https://github.com/ProjectURL

# 方式二：SSH（需预先配置 SSH 密钥）
git clone git@github.com:username/repository.git

# 方式三：GitHub CLI
gh repo clone username/repository

克隆完成后进入项目目录即可开始工作：

cd ProjectURL

不克隆也能开工的现代工作方式

除了本地克隆，GitHub 还提供了若干"打开即开发"的途径，非常适合新人快速上手：

GitHub Codespaces：GitHub 的云端开发环境，在浏览器中直接运行 VS Code，零本地安装；
GitHub Desktop：面向 Git 操作的桌面图形化应用；
GitHub.dev：在任意 GitHub 仓库页面按下 .（句点）键，即可在浏览器中打开 VS Code 界面；
VS Code + GitHub Pull Requests 扩展：在编辑器内完成评审与 PR 操作。

此外，也可以直接下载仓库代码的 ZIP 压缩包——虽不保留 Git 历史，但对纯阅读场景足够。

GitHub 生态功能一览

最后，本课还带我们浏览了 GitHub 平台上那些"让开发更丰富"的周边能力：

Star（加星）/ Watch（关注）/ Fork（派生）：任何公开仓库都可以加星、关注或派生。Star 过的仓库可从右上角下拉菜单找到——相当于"给代码用的书签"；
Issues（问题跟踪）：项目的 Issue 跟踪器通常位于 Issues 标签页，社区在此讨论与项目相关的缺陷、需求与规划；
Pull Requests 标签页：在此讨论与评审进行中的代码改动；
社区渠道：部分项目还使用论坛、邮件列表或 Slack / Discord / IRC 等聊天频道组织讨论；
现代功能家族：GitHub Discussions（内置社区论坛）、GitHub Sponsors（资助维护者）、Security 标签页（漏洞报告与安全公告）、Actions 标签页（查看自动化工作流与 CI/CD 流水线）、Insights 标签页（贡献者、提交与项目健康度分析）、Projects 标签页（内置项目管理工具）。

动手建议：围绕你新建的仓库做一轮"试操作"——修改设置、向仓库补充信息、创建一个项目看板（Kanban）、配置一个 GitHub Actions 自动化工作流。可探索的空间非常大，实践是最好的老师。

课后挑战与练习路线

协作挑战

找一位朋友（或总在好奇你"在电脑上捣鼓什么"的家人）一起完成一次结对协作：共同创建项目、让对方 Fork、建立若干分支、像真正的团队一样合并改动。过程中你们大概率会笑场（尤其是两人同时修改同一行时）、也会挠头困惑，但一定会收获让一切知识"串联起来"的顿悟时刻。没有搭档？没问题——在 GitHub 上寻找带 good first issue 标签的仓库，它们本质上就是在喊话："新手们，来和我们一起学吧！"

结语

至此，你已经走完了从"看着 GitHub 页面一头雾水"到"拥有自己的远程仓库、理解本地提交循环、能按 PR 流程给他人项目合入代码"的完整进阶路径。回顾本文的核心链条：本地 git add/commit/push 三连驱动个人仓库 → 用社区标准文件与 CI 基建把仓库打磨得"欢迎贡献" → 以 Fork + 分支 + Pull Request 汇入外部协作 → 带着 good first issue 方法论迈向开源。

请记住：每一个"看起来像魔法师"的资深开发者，都曾为第一个 PR 而紧张到手指发抖。本文所在的 Web-Dev-For-Beginners 仓库本身就是一个巨大的开源协作样本——它通过根目录的 CONTRIBUTING.md 等文档组织贡献流程，依赖遍布全球的贡献者共同维护。你的第一次贡献可能微小，但每个大型开源项目都始于某人的第一次提交。工具已就绪，剩下的就是用实践把它变成肌肉记忆。

Web-Dev-For-Beginners

24 Lessons, 12 Weeks, Get Started as a Web Developer

项目地址：https://gitcode.com/GitHub_Trending/we/Web-Dev-For-Beginners

登录后查看全文