Web-Dev-For-Beginners：从零建立 Git 工作流到上手 GitHub 协作的完整实战指南

2026-09-06 11:30:21作者：段琳惟

本文基于 Web-Dev-For-Beginners 课程的第 2 课《Introduction to GitHub》，系统讲解从 Git 安装配置、创建第一个仓库、日常提交节奏，到 Fork/分支/Pull Request 协作流程与开源贡献的完整路径。读完后，你将能够独立完成本地代码的版本管理，并以标准工作流参与他人项目的贡献。

一、课程定位与学习目标

本课程（"24 Lessons, 12 Weeks, Get Started as a Web Developer"）将 Git 与 GitHub 安排在起步阶段（第 1 阶段第 2 课），因为后续所有课程项目——terrarium、打字游戏、浏览器扩展、太空射击游戏、银行系统、聊天项目——都依赖版本管理来保存进度、协作与交付。本课对应源文档为 1-getting-started-lessons/2-github-basics/README.md，整课覆盖三大主题：

跟踪本机上的工作（version control）；
与他人协作开发项目；
如何向开源软件贡献代码。

原课程用一张"旅程图"概括了全课的三个章节：Setup（安装 Git、创建账户、创建第一个仓库）、Master Git（本地变更、提交与推送、分支）、Collaborate（Fork 项目、Pull Request、开源贡献）。本文按同样的脉络展开，并结合本仓库内的 Git-Basics/README.md 命令速查表进行扩充。

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

2.1 检查并安装 Git

Git 是分布式版本控制系统：完整的代码库与历史存在于每位开发者的电脑上，因此可以自由地建立分支与合并。它记录每一次文件变更的"快照"，并支持随时回退到任意历史点。

首先检查本机是否已安装 Git：

git --version

如果没有安装，请前往 Git 官网（git-scm.com/downloads）下载对应系统的安装包。仓库内的 Git-Basics/README.md 补充了各平台的安装方式，供参考：

# Linux (Debian)
sudo apt-get install git

# Linux (Fedora)
sudo yum install git

macOS 与 Windows 则从官网下载安装包。

2.2 首次全局配置

安装后需要告诉 Git"你是谁"。这条信息会附加到你之后的每一个 commit 上，因此建议使用你愿意公开展示的姓名与邮箱：

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

查看当前 Git 的全部配置（确认上面两项已生效）：

git config --list

2.3 其余前置条件

一个 GitHub 账户（若尚未注册，请到 GitHub 官网创建并完善个人资料）；
一款代码编辑器，如 Visual Studio Code；
会打开终端（Windows 上为命令提示符 / Command Prompt）。

需要说明：GitHub 并非世界上唯一的代码托管服务，但它是最广为人知的那一个。

三、与 GitHub 协作的安全最佳实践

课程特别强调从第一天就建立安全习惯，就像"锁好门窗"一样自然。原课给出的安全实践清单如下：

安全领域	最佳实践	为什么重要
身份认证（Authentication）	使用 SSH 密钥或 Personal Access Token	密码方式安全性较低且正在被淘汰
双因素认证（2FA）	在 GitHub 账户上开启 2FA	为账户增加一层保护
仓库安全（Repository Security）	绝不提交敏感信息	API 密钥和密码永远不应出现在公开仓库中
依赖管理（Dependency Management）	启用 Dependabot 自动更新	保持依赖项安全且及时

关键安全提醒：永远不要把 API 密钥、密码或其他敏感信息提交到任何仓库。应使用环境变量与 .gitignore 文件来保护敏感数据。本仓库自身也体现了这一规范：根目录下的 SECURITY.md 单独定义了漏洞上报流程（不通过公开 Issues 报告漏洞），CODE_OF_CONDUCT.md 定义了社区行为准则，这些正是课程要求仓库具备的"Security Policy"与"Code of Conduct"文件。

3.1 用 SSH 密钥替代密码认证

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

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

SSH 密钥免去了反复输入密码的步骤，且比传统认证方式更安全。Git-Basics/README.md 的远端命令表中同样收录了 git remote add origin 与 git remote set-url origin（SSH 形式），可交叉对照。

四、Git 与 GitHub 的概念区分

初学阶段最容易混淆的一点：Git 是软件，GitHub 是云服务。仓库内的 Git-Basics/README.md 用一张对照表把区别讲得很清楚：

Git	GitHub
是软件（版本控制系统）	是云服务（源代码托管）
安装在本地系统上	托管在云端
命令行工具	提供图形界面
专注版本控制与代码共享	专注集中式代码托管、协作功能
2005 年发布	2008 年发布

也就是说：git 命令在你的电脑上完成暂存、提交、分支等一切操作；git push / git pull / git clone 则是 Git 与 GitHub 之间的"传输层"。

五、创建你的第一个仓库：完整九步走

这是本课的核心实操任务。整体流程如下（流程图继承自原课文档）：

flowchart TD
    A[项目文件] --> B{是 Git 仓库吗?}
    B -->|否| C[git init]
    B -->|是| D[进行修改]
    C --> D
    D --> E[git add .]
    E --> F["git commit -m 'message'"]
    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[贡献完成]

5.1 在 GitHub 网页上创建仓库

登录 GitHub，找到右上角醒目的 New（或 +）按钮，选择 New repository；
给仓库起一个有意义的名字；
可添加描述（description），帮助他人理解项目；
选择 public（所有人可见）或 private（仅自己可见）；
建议勾选初始化 README——它是项目的"门面"；
点击 Create repository，第一个仓库即创建完成。

5.2 进入项目目录并初始化本地仓库

打开终端，进入你的项目文件夹：

cd [你的文件夹名]

把普通文件夹变成 Git 仓库：

git init

这一步后，Git 会在项目中创建一个隐藏的 .git 目录，普通文件夹从此具备"记住一切变更"的能力。接着查看仓库当前状态：

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.3 暂存（staging）与提交（commit）

git add .

. 表示"本目录下所有变更"。也可以只暂存特定文件，便于把相关改动组织成逻辑块：

git add [文件或文件夹名]

如果选错了，可以取消暂存（不会删除任何工作，只是把文件从"待保存"堆里拿出来）：

# 取消全部暂存
git reset

# 只取消某个文件的暂存
git reset [文件名]

然后做第一次提交：

git commit -m "first commit"

此时 Git 对全部已暂存文件拍了一张"快照"：提交信息说明这个保存点的内容，Git 为该快照分配唯一 ID，项目历史由此开始。

5.4 关联远端并首次推送

git remote add origin https://<仓库地址>

将地址替换为你仓库页面的实际 URL。"origin"只是给远端仓库起的昵称，相当于手机通讯录里的一个联系人。如果安装了 GitHub CLI，也可以一条命令完成"建仓库+关联+推送"：

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

推送代码到 GitHub：

git push -u origin main

-u（--set-upstream）会建立本地分支与远端分支的固定关联，此后只需输入 git push 即可；
main 是主分支名；如果你的分支叫其他名字（如 master），请替换为该名字，可用 git branch --show-current 确认当前分支。

Git-Basics/README.md 的"Sharing & Updating"命令表给出了同一组命令的系统速查：git push -u origin [branch]、git push、git pull、git remote add origin ...，适合打印在显示器旁备查。

5.5 每日开发节奏：add → commit → push

从今以后，每次改动代码都执行这个"三步舞"：

git add .
git commit -m "描述你改了什么"
git push

这个节奏相当于游戏里的多个存档点：改动的效果满意？提交它！想尝试有风险的大改动？没问题——随时可以回退到上一个提交。

.gitignore 补充：建议为项目引入 .gitignore 文件，让不需要上传的文件（如本地笔记、依赖目录）不出现在 GitHub 上。GitHub 官方维护了常见语言的 .gitignore 模板集合，可据此创建。

六、如何写出高质量的 Commit Message

原课给出的核心判定标准是一句话测试：

一条优秀的 commit 主题行，能够完整这句话：If applied, this commit will _____（如果应用了这次提交，将会______）。

写作要点：

主题与正文都使用祈使句、现在时："change" 而不是 "changed" / "changes"；
正文（可选部分）应说明改动的动机（why），并与旧行为形成对比，而不是描述"怎么做的"（how）；
例如用 "Add contact form to homepage"、"Fix navigation menu bug"，而不是 "updated stuff"。

原课还推荐三种现代提交实践：

Conventional Commits：采用 feat:、fix:、docs: 等标准化前缀；
原子提交（Atomic commits）：每个提交只表达一个逻辑变更；
频繁提交：用小而勤、描述清晰的提交，代替大而稀的提交。

Git-Basics/README.md 的"Inspection & Comparison"部分列出的 git log、git log --oneline、git diff [source] [target] 正是回看与预览这些提交的工具。

七、协作工作流：从 Fork 到 Pull Request

把代码放到 GitHub 上的首要目的，就是让协作成为可能。完整协作链路（继承自原课文档）：

flowchart LR
    A[找到项目] --> B[Fork 仓库]
    B --> C[克隆到本地]
    C --> D[创建分支]
    D --> E[进行修改]
    E --> F[提交变更]
    F --> G[推送分支]
    G --> H[创建 Pull Request]
    H --> I{维护者评审}
    I -->|通过| J[Merge!]
    I -->|要求修改| K[更新代码]
    K --> F
    J --> L[清理分支]

7.1 贡献者的四步模型

维护者通常期望贡献者按如下顺序行事：

Fork——在你的 GitHub 账户下复制一份仓库副本；
Clone——把副本克隆到自己的本地机器；
创建分支——在自己的分支上开展工作；
聚焦单一改动——一次只改一处。想象一下贡献者同时写了 bug 修复、新功能、更新了三组测试，而维护者只想采纳其中两项：改动越聚焦，被 merge 的概率越高。

提醒：这些规范同样适用于你自己的工作——你现在位于哪个分支，commit 就会落在哪个分支上；用 git status 可随时确认当前分支。

7.2 分支工作流逐步演练

假设贡献者已完成 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，再合并回本分支

main 分支在你开发期间可能已经变化，先把它更新到最新：

git switch main
git pull

然后回到工作分支，把 main 的新变更合入（这样任何冲突都会发生在你的分支上，而不是污染 main）：

git switch [branch-name]
git merge main

git merge main 会把 main 的全部变更带入你的分支。若无冲突可直接继续；若 Git "困惑"了（出现冲突），编辑器（如 VS Code）会标出冲突位置，你只需逐一确认哪份内容才是准确的。

现代替代方案——用 rebase 得到更线性的历史：

git rebase main

它会把你的提交依次"重放"到最新的 main 之上。

第 5 步：把分支推送到 GitHub

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

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

7.3 发起 Pull Request 与合并后清理

发起 PR：到 fork 仓库的 GitHub 页面，当分支首次推送后，GitHub 会提示你是否创建 PR。点击后进入 PR 界面，你可以调整标题、补充更合适的描述。维护者看到 PR 后，若认可便会 merge 你的改动——从这一刻起，你就是贡献者了。

用 GitHub CLI 也可以发起：

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

PR 最佳实践（原课清单）：

用 "Fixes #123" 之类的关键字关联相关 issue；
UI 改动附上截图；
指定具体评审人；
进行中的工作使用 draft PR；
请求评审前确保所有 CI 检查通过。

合并后清理：本地删除分支，再去 GitHub 页面上删除远端分支：

git branch -d [branch-name]

"Pull Request"到底在请求什么？ 这个词看似别扭——实际上你是想把改动推给项目。但维护者（或核心团队）需要在改动进入项目主分支之前先审视它，所以你本质上是在向维护者请求一个合并决定。PR 页面就是比较与讨论分支差异的地方：评审、评论、集成测试都在此进行。好的 PR 遵循与 commit message 类似的规则——描述清楚改了什么、为什么改；可以用 # + issue 编号（如 #97）引用 issue 跟踪器中的条目。最后别忘了用 git pull 把远端对应分支上的新提交同步到本地当前分支。

7.4 本仓库的实际协作约定

以本仓库为例，CONTRIBUTING.md 说明了真实的贡献门槛：大多数贡献需要签署贡献者许可协议（CLA），提交 PR 后 CLA-bot 会自动判定并打标签/评论，按提示操作即可，且整个 Microsoft 系仓库只需签署一次。这正是"Insights > Community 社区标准"所倡导的"让贡献者事先知道流程"的落地示范。

八、仓库社区标准与现代 GitHub 功能

8.1 用 Insights > Community 自检

在任意仓库页面进入 Insights > Community，可以看到你的项目与 GitHub 社区推荐标准的差距。原课给出的"让仓库更专业"清单：

应添加的文件	为什么重要	带来的作用
Description	第一印象	他人立刻知道项目做什么
README	项目门面	像友好的向导接待新访客
贡献指南（Contributing）	表示欢迎参与	他人知道如何帮你
行为准则（Code of Conduct）	营造友好空间	人人乐于参与
License	法律清晰度	他人知道如何使用你的代码
安全策略（Security Policy）	体现责任感	展示专业实践

GitHub 在创建仓库时提供这些文件的模板，勾选即可自动生成。本仓库恰好六项齐全：README.md、CONTRIBUTING.md、CODE_OF_CONDUCT.md、SECURITY.md、LICENSE，可以直接打开对照学习。

8.2 值得探索的现代功能

自动化与 CI/CD：

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

社区与项目管理：

GitHub Discussions——issue 之外的社区讨论区；
GitHub Projects——看板（Kanban）式项目管理；
Branch protection rules——强制代码质量标准的分支保护规则。

这些资源最终都服务于同一目标：帮助新成员顺利入职。新贡献者往往在看你的代码之前，就先浏览这些文件来判断"这个项目是否值得我花时间"。本仓库自身就是一个活例子：根 README.md 声明其 50+ 语言翻译正是通过 GitHub Action 自动生成的，且文档化了如何用 sparse checkout 加速克隆：

git clone --filter=blob:none --sparse <仓库地址>
cd Web-Dev-For-Beginners
git sparse-checkout set --no-cone '/*' '!translations' '!translated_images'

九、开源贡献路径

9.1 找到对初学者友好的仓库

一个好的起步方式是按 good first issue 标签搜索——这类标签就是项目方对新手说"来和我们一起练手吧"。本课程的练习章节同样推荐"找朋友一起 fork、建分支、合并"来实战全部流程。

9.2 把代码拿到本地

克隆仓库有三种方式（HTTPS / SSH / GitHub CLI）：

# 使用 HTTPS
git clone https://<ProjectURL>

# 使用 SSH（需先配置 SSH 密钥）
git clone git@github.com: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 压缩包（但不含 Git 历史，无法参与协作）。

9.3 GitHub 上还可以做什么

对任何公开仓库 Star（类似收藏）、Watch（关注动态）、Fork（复制到自己账户）；Star 过的仓库可在右上角菜单找到；
项目的 Issues 页是讨论项目问题的追踪器，Pull Requests 页评审进行中的变更；
项目还可能在论坛、邮件列表、Slack/Discord/IRC 频道中组织讨论。

原课列出的现代功能 Tab 一览：Discussions（内置论坛）、Sponsors（资助维护者）、Security（漏洞报告与安全公告）、Actions（自动化流水线）、Insights（贡献者/提交分析）、Projects（内置项目管理）。练习建议：打开你新建的仓库，试着改设置、补信息、建一个看板、配置一个 GitHub Actions 自动化。

十、实战挑战与进阶路线图

10.1 本课的 Copilot Agent Challenge

原课为 Agent 模式设置了一道综合练习，恰好覆盖了全文知识点：创建一个公开的 "Web Development Resources" 仓库，README 按 HTML/CSS/JavaScript 等分类整理资源；配置 License、贡献指南、行为准则等社区标准；分别创建"添加 CSS 资源"与"添加 JavaScript 资源"两个 feature 分支，用描述性提交信息提交，再开 PR 合并回 main；同时启用 Issues、Discussions，并配置一个基础的 GitHub Actions 自动检查流程。

10.2 分阶段练习清单

原课按时间尺度给出了一份可勾选的成长路线，摘选关键项：

接下来 5 分钟可完成：Star 本课仓库及 3 个感兴趣的项目；开启账户双因素认证；为第一个仓库写一份简单 README。

这一小时内可完成：设置 SSH 密钥实现免密认证；用一条出色的提交信息完成一次有意义的提交；练习 Fork 一个仓库并做一个小改动。

本周：完成 GitHub Skills 的《Introduction to GitHub》《Communicate using Markdown》课程；向一个开源项目发起人生第一个 Pull Request；为仓库补齐社区标准文件（README、License 等）；尝试 Codespaces 云端开发。

本月：向 3 个不同的开源项目贡献代码；用 GitHub Actions 搭建自动化工作流；建立展示你贡献记录的 portfolio。

10.3 仓库内的延伸学习入口

Git-Basics/README.md：完整的 Git 命令速查表（快照、分支、共享、检视四大类），是本课命令的"字典版"；
1-getting-started-lessons/README.md：第 1 阶段课程索引，本课前一课是编程语言入门、后一课是无障碍（Accessibility）；
CONTRIBUTING.md / SECURITY.md / CODE_OF_CONDUCT.md：社区标准文件三件套的现成范本，可直接借鉴到你自己的仓库中。

小结

Git 提供"每一次改动都可追溯、可回滚"的本地历史能力，GitHub 在此之上叠加了 Fork、分支、Pull Request、社区标准与自动化等协作基础设施。本课的核心产出是一个可复用的心智模型：git init 建立仓库 → git add / git commit 保存快照 → git push 同步云端 → Fork/分支/PR 完成协作闭环。把这些命令变成肌肉记忆需要刻意练习——从今天起，把 git add . && git commit -m "描述" && git push 作为你保存工作的固定节拍即可。

Web-Dev-For-Beginners

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

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

登录后查看全文