教学网站 · 协作基础
Git vs GitHub：理解两者的根本区别
Git 是版本控制工具（VCS）——管你本地代码的历史； GitHub 是托管服务（SaaS）——在 Git 之上加了 PR、Issue、Review、Actions 等协作功能。 很多人把两者混为一谈，理解这个区别是理解一切开源协作（PR / Fork / Code Review）的前提——也是理解为什么 SWE-bench 题目都长成「真实 GitHub issue + fix PR」这种形态的前提。
概览
2
系统本质不同
7
核心差异维度
2005
Git 诞生年
2008
GitHub 诞生年
| 项目 | 说明 |
|---|---|
| 本卡定位 | 协作基础 · 1.0 章节 第 1 张 |
| 前置 | 无（懂命令行即可） |
| 读完会什么 | 能清楚区分 Git（工具）和 GitHub（服务）；能解释为什么 SWE-bench 题目都长成「issue + PR」形态 |
| 姊妹讲义 | github-pull-request.html（PR 设计）；build-problem-from-pr.html（题目构造） |
§ 1 一句话对比
Git = 工具（你装在电脑上的软件，做版本控制）
GitHub = 服务（一个网站，托管你的 Git 仓库，附加协作功能）
类比：Git 像 git 命令，GitHub 像 GitHub.com ——一个是本地的工具，一个是云端的服务。Git 不依赖 GitHub 存在（你也可以把 Git 仓库放在自己的服务器 / GitLab / Gitee 上）；GitHub 也只是众多 Git 托管服务之一（其他还有 GitLab、Bitbucket、Gitee、Codeberg）。
GitHub = 服务（一个网站，托管你的 Git 仓库，附加协作功能）
类比：Git 像 git 命令，GitHub 像 GitHub.com ——一个是本地的工具，一个是云端的服务。Git 不依赖 GitHub 存在（你也可以把 Git 仓库放在自己的服务器 / GitLab / Gitee 上）；GitHub 也只是众多 Git 托管服务之一（其他还有 GitLab、Bitbucket、Gitee、Codeberg）。
flowchart TB
subgraph 上层["上层 · 托管服务（SaaS，可替换）"]
GH["GitHub
在 Git 之上加：PR / Issue / Review / Actions / Wiki"] GL["GitLab"] GE["Gitee / Bitbucket / Codeberg"] end GIT["底层 · Git（本地版本控制工具 / 协议）
commit / branch / merge / push / pull"] GH -->|建在 Git 之上| GIT GL --> GIT GE --> GIT
在 Git 之上加：PR / Issue / Review / Actions / Wiki"] GL["GitLab"] GE["Gitee / Bitbucket / Codeberg"] end GIT["底层 · Git（本地版本控制工具 / 协议）
commit / branch / merge / push / pull"] GH -->|建在 Git 之上| GIT GL --> GIT GE --> GIT
§ 2 Git 是什么：分布式版本控制工具
Git 是 2005 年 Linus Torvalds（Linux 之父）为管理 Linux 内核代码而开发的分布式版本控制系统（DVCS）。
Git 的 3 个核心抽象
| 概念 | 是什么 | 比喻 |
|---|---|---|
| Commit（提交） | 代码在某一时刻的完整快照（含全部文件 + 父 commit 引用） | 文档的"保存点"——可以随时回退 |
| Branch（分支） | 指向某个 commit 的轻量级指针（不是拷贝） | 文档的"副本"——但共享历史，可以合并 |
| Merge / Rebase | 把两个分支的历史合并（merge 保留拓扑，rebase 改写历史） | 两个副本的合并——可以自动合并也可以冲突手解 |
Git 的"分布式"是什么意思
传统 VCS（SVN / CVS）只有一个中央服务器保存所有历史，开发者本地只有当前版本。Git 把完整历史复制到每个开发者的本地——你 git clone 一下，就有了整个项目的所有 commit、所有 branch、所有 tag。
| 维度 | SVN（集中式） | Git（分布式） |
|---|---|---|
| 本地有完整历史？ | ❌ 只有当前版本 | ✅ git clone 拉整个仓库 |
| 提交需要联网？ | ✅ 必须连中央服务器 | ❌ git commit 本地即可 |
| 断网能看历史？ | ❌ | ✅ git log 离线也能看 |
| 分支代价 | 高（拷贝目录） | 极低（41 字节的指针） |
Git 的本质：Git 是一个内容寻址的文件系统——每个文件按 SHA-1 hash 存，commit 引用父 commit 的 hash，branch 引用 commit 的 hash。没有"中央"概念，"中央服务器"只是大家约定俗成用来同步的"那个仓库"。
§ 3 GitHub 是什么：托管服务 + 协作平台
GitHub 是 2008 年上线的基于 Git 的代码托管与协作平台——2023 年被 Microsoft 收购。它在 Git 的"本地工具"之上，提供了一整套"协作功能"。
GitHub 的 8 大核心功能
| 功能 | 作用 |
|---|---|
| Remote Repository | 把 Git 仓库托管在云端，git push / git pull 同步 |
| Pull Request（PR） | 提议把 A 分支的改动合并到 B 分支——带 review、conversation、checks |
| Issue | 任务 / Bug / Feature 追踪——带 label、milestone、assignee |
| Fork | 把别人的仓库复制到自己的账号下——提 PR 的前提 |
| Code Review | PR 内的逐行评论、approval、requested changes |
| Actions（CI/CD） | 仓库内置的 CI/CD（Continuous Integration / Continuous Delivery，持续集成 / 持续交付）平台——push 触发自动跑测试 |
| Wiki / Projects / Discussions | 文档、看板、社区讨论 |
| Security | Dependabot 依赖更新、Code Scanning 代码扫描、Secret Scanning 密钥扫描 |
3 个关键概念（GitHub 独家）
| 概念 | Git 命令视角 | GitHub 视角 |
|---|---|---|
| Remote（远端） | git remote add origin https://github.com/<owner>/<repo>.git | 网页上看到的那个仓库 = remote URL 指向的仓库 |
| Fork | 没有对应命令 | 网页上一键把别人的仓库复制到你账号下（自动创建新 remote） |
| Pull Request | git pull 是拉代码 | PR = "请你 pull 我的代码" 的请求——一个协作流程，不是一条命令 |
GitHub 不是什么：GitHub 不是 Git 的"升级版"或"云端版"——它是一个独立的产品，建在 Git 之上，但可以独立于 GitHub 存在。你可以：用 Git 但不用 GitHub（自建服务器 / 用 GitLab / 局域网内用 Git）；用 GitHub 但只在网页上浏览（不装 Git 客户端）；只用 GitHub 的某些功能（不强制全套用）。
§ 4 Git vs GitHub · 7 个核心差异
7 个核心差异（一眼对比）
| 维度 | Git（工具） | GitHub（服务） |
|---|---|---|
| 本质 | 命令行工具 / 桌面应用 | 云端 SaaS 网站 |
| 运行位置 | 本地（git --version） | 云端（github.com） |
| 诞生时间 | 2005 年（Linus Torvalds） | 2008 年（Tom Preston-Werner 等） |
| 核心用户 | 开发者本人（管自己的代码） | 团队 / 开源社区（多人协作） |
| 主要能力 | commit / branch / merge / rebase | PR / Issue / Review / Actions / Wiki |
| 协作方式 | push / pull（手动同步） | PR + Review + Conversation（结构化流程） |
| 是否需要联网 | 本地操作不需要 | 基本功能都需联网（除本地缓存） |
最容易混淆的 3 个对应
| 容易混淆 | 实际差异 |
|---|---|
| "commit 上去" | 错。commit 是本地操作；要"上去"需要 git push 到 GitHub |
| "在 GitHub 上 fork" | Git 命令行没有 git fork；fork 是GitHub 网站的功能，复制别人的仓库到你的账号 |
| "发 PR 给某人" | PR 是GitHub的概念；Git 命令行的 git request-pull 是非常底层的命令，几乎没人用——PR 是 GitHub 在这之上的产品化 |
§ 5 类比记忆：3 个生活化类比
类比 1：Git vs GitHub = 邮件协议 vs Gmail
· Git 像 SMTP / IMAP（邮件协议）——规定消息怎么发、怎么收
· GitHub 像 Gmail（基于 SMTP 的邮件服务）——在协议之上加了收件箱、垃圾邮件过滤、广告
· 你可以换其他邮件服务（Outlook / Yahoo），但邮件协议不变
· 你可以不用 Gmail 用自己的邮件服务器，但大多数人选 Gmail 因为方便
· Git 像 SMTP / IMAP（邮件协议）——规定消息怎么发、怎么收
· GitHub 像 Gmail（基于 SMTP 的邮件服务）——在协议之上加了收件箱、垃圾邮件过滤、广告
· 你可以换其他邮件服务（Outlook / Yahoo），但邮件协议不变
· 你可以不用 Gmail 用自己的邮件服务器，但大多数人选 Gmail 因为方便
类比 2：Git vs GitHub = Word 的"修订历史" vs Google Docs
· Git 像 Word 的"修订历史"——你能看到每一版、回退到任何版本、比较版本差异
· GitHub 像 Google Docs——在历史之上加了多人同时编辑、评论、@提醒、权限管理
· Word 文档可以脱离 Google Docs 存在；Google Docs 也只是众多协作工具之一
· Git 像 Word 的"修订历史"——你能看到每一版、回退到任何版本、比较版本差异
· GitHub 像 Google Docs——在历史之上加了多人同时编辑、评论、@提醒、权限管理
· Word 文档可以脱离 Google Docs 存在；Google Docs 也只是众多协作工具之一
类比 3：Git vs GitHub = git 命令 vs GitHub 网页/桌面客户端
· Git 是一组 git xxx 命令（commit / push / pull / merge / rebase）
· GitHub 提供等价的图形化操作——网页上点 "Commit" 按钮、点 "Merge PR" 按钮
· 底层都是 Git 命令；GitHub 是更友好的"前端"
· 但功能不完全等价——GitHub 独有 PR Review / Actions / Wiki 等，git 命令做不到
· Git 是一组 git xxx 命令（commit / push / pull / merge / rebase）
· GitHub 提供等价的图形化操作——网页上点 "Commit" 按钮、点 "Merge PR" 按钮
· 底层都是 Git 命令；GitHub 是更友好的"前端"
· 但功能不完全等价——GitHub 独有 PR Review / Actions / Wiki 等，git 命令做不到
§ 6 为什么要理解这个区别（特别是对 SWE-bench）
理解 Git vs GitHub 看似抽象，对理解 SWE-bench（SWE = Software Engineering，软件工程；bench = benchmark，基准测试——用真实 GitHub issue 评测代码 agent 的软件工程基准，见 SWE-bench 入门）和开源协作至关重要。
4 个实际意义
- 理解 SWE-bench 题目的"形状"：每条 SWE-bench 题目都是"GitHub issue（用户报的问题）+ 对应的 GitHub PR（开发者修的代码）"。没有 GitHub 就不会有 SWE-bench——因为题目源就是 GitHub 上的真实协作记录。
- 理解"git 协议"在 PR 里怎么用：base_commit 字段就是 Git commit hash，patch 字段就是 git diff 输出，test_patch 是 git apply 的输入。没有 Git 就没有 SWE-bench 评测的"起点 / 答案"。
- 理解"为什么用 GitHub"而不是自己造：SWE-bench 的"真实 issue"不是作者编的，是从 GitHub 公开仓库的历史里挖出来的。用 GitHub 的好处：① 题目真实（真用户报的问题）② 答案真实（真开发者修的）③ 评测客观（GitHub 提供的 commit hash 和 PR diff 是不可篡改的"真相"）。
- 理解"协作功能"是 GitHub 的护城河：Git 是开源的、任何人都可以复刻——GitLab / Bitbucket / Gitee 都是 Git 的实现。GitHub 的护城河是网络效应：90% 的开源项目在 GitHub 上，所以 SWE-bench 题目源也在 GitHub。GitHub 是开源世界的"事实中央"。
一个直观的类比：如果 SWE-bench 是一道考题，
· Git 是"答题用的笔"——commit / diff / patch 这些机制
· GitHub 是"题库"——issue + PR 这些真实数据
· SWE-bench 是"考试流程"——出题（拉 PR）→ 答题（agent 写 patch）→ 阅卷（跑测试）
没有 Git 这个笔，题没法出；没有 GitHub 这个题库，题目就假了；没有 SWE-bench 这个流程，agent 没法量化评测。
· Git 是"答题用的笔"——commit / diff / patch 这些机制
· GitHub 是"题库"——issue + PR 这些真实数据
· SWE-bench 是"考试流程"——出题（拉 PR）→ 答题（agent 写 patch）→ 阅卷（跑测试）
没有 Git 这个笔，题没法出；没有 GitHub 这个题库，题目就假了；没有 SWE-bench 这个流程，agent 没法量化评测。
§ 7 速查表：Git vs GitHub 一图分清
| 维度 | Git | GitHub |
|---|---|---|
| 类型 | 工具（VCS） | 服务（SaaS） |
| 运行位置 | 本地 | 云端 |
| 创造者 | Linus Torvalds（2005） | Tom Preston-Werner 等（2008） |
| 协议 | 开源（GPL v2） | 专有（被 Microsoft 收购） |
| 核心命令 | git commit / git push / git pull | （无命令，通过网页 / API） |
| 核心功能 | commit / branch / merge / rebase | PR / Issue / Review / Actions / Wiki |
| 协作方式 | push / pull（手动） | PR + Review（结构化） |
| 是否需要账号 | ❌（本地用） | ✅ |
| 数据存在 | 本地 .git/ 目录 | 云端服务器 |
| 历史可改吗 | ✅ git rebase / git commit --amend | ❌ GitHub PR 合并后不可改（force push 受限） |
| 替代品 | SVN / Mercurial（已边缘化） | GitLab / Bitbucket / Gitee / Codeberg |
| SWE-bench 怎么用 | 用 commit hash、git diff 输出作题目字段 | 用 issue body、PR diff 作题目源 |
引用与配套资料
| 来源 | 链接 / 路径 | 说明 |
|---|---|---|
| Git 官方文档 | git-scm.com/doc | Git 工具官方文档 |
| Pro Git（免费电子书） | git-scm.com/book/en/v2 | Scott Chacon 著，最权威的 Git 教程 |
| GitHub 官方文档 | docs.github.com/en | GitHub 平台官方文档 |
| GitHub 培训 | skills.github.com | GitHub 官方交互式教程 |
| 本仓姊妹讲义 | github-pull-request.html | Pull Request 设计 |
| 本仓姊妹讲义 | build-problem-from-pr.html | 从 PR 构造 Benchmark 题目 |
| 本仓姊妹讲义 | swe-bench-intro.html | SWE-bench 是什么 |
| 本仓姊妹讲义 | swe-bench-data-schema.html | SWE-bench 数据 schema |