这是一个很好的问题。GitHub 在 Git 之上确实引入了不少”非标准”或”扩展”特性，有些甚至和 Git 原生的设计哲学产生了微妙的张力。我来系统梳理一下：
1. Pull Request（最核心、最显著的差异）
| 维度 | 标准 Git | GitHub |
|---|---|---|
| 协作模型 | 直接 push/merge | 通过 fork + PR 间接合并 |
| 权限假设 | 所有协作者都有仓库写权限 | 贡献者通常没有上游仓库写权限 |
| 代码审查 | 无内置机制 | PR 内置 Review、Comment、Approve |
| 讨论空间 | commit message | PR 页面成为主要讨论场所 |
本质差异：Git 假设协作双方是平等的（都有写权限），GitHub 则假设贡献者和维护者是不平等的。
2. Fork 与”伪分布式”
Git 的设计是真正分布式的——每个 clone 都是完整的仓库，没有”中心”概念。
但 GitHub 的 Fork 机制实际上在心理上和流程上制造了一个”中心”：
- 你的 fork 是”副本”，上游是”正本”
- PR 只能从一个 fork 指向另一个仓库
- 虽然技术上任何两个仓库都可以互相 push/pull，但 GitHub 的 UI 和流程都围绕”上游-下游”展开
这导致很多人误以为 Git 是”中心化”的——其实 Git 本身不是，是 GitHub 的 UX 让它看起来像。
3. Issues、Wiki、Projects、Actions——这些都不是 Git
| 功能 | 是否属于标准 Git | 说明 |
|---|---|---|
| Issues（议题） | ❌ 不是 | GitHub 的独立数据库系统 |
| Wiki | ❌ 不是 | GitHub 自己的 Wiki 引擎 |
| Projects（看板） | ❌ 不是 | GitHub 的项目管理工具 |
| Actions（CI/CD） | ❌ 不是 | GitHub 的自动化平台 |
| Releases | ❌ 不是 | 基于 Git tag 的附加功能 |
| Discussions | ❌ 不是 | 论坛功能 |
这些功能的数据不存储在 Git 仓库里，而是 GitHub 自己的数据库中。如果你把仓库 clone 到本地，这些信息是拿不到的。
4. Merge 策略的”魔法”
GitHub 提供了几种 PR 合并方式，这些在标准 Git 里需要手动操作：
| 方式 | 标准 Git 等价操作 | GitHub 的便利 |
|---|---|---|
| Create a merge commit | git merge --no-ff | 一键完成，自动生成 PR 编号引用 |
| Squash and merge | git merge --squash + 手动 commit | 自动压缩所有 commit，重写历史 |
| Rebase and merge | git rebase + git merge --ff-only | 自动变基，保持线性历史 |
GitHub 的 PR 合并还会自动：
- 在 commit message 中插入
Closes #123等关键字来关联 Issue - 触发 Webhook 通知外部系统
- 在 PR 页面显示合并后的状态
5. Protected Branches（分支保护）
标准 Git 对分支没有任何权限控制——只要你有仓库访问权，你可以对任何分支做任何事。
GitHub 引入了分支保护规则：
- 禁止直接 push 到
main - 强制要求 PR + Review
- 强制要求 CI 通过
- 要求签名 commit
这在 Git 原生中完全不存在，是 GitHub 在服务器端的逻辑层实现的。
6. GitHub Flavored Markdown（GFM）
GitHub 对标准 Markdown 做了大量扩展：
@username提及用户#123引用 Issue/PRsha自动链接到 commit- Task lists (
- [ ]) - Emoji
:rocket: - Mermaid 图表、数学公式等
这些在标准 Markdown 或 Git 中都不存在。
7. Git LFS（Large File Storage）
Git 本身不擅长处理大文件（视频、二进制资源等），因为每次改动都会保存完整副本，导致仓库膨胀。
GitHub 推出了 Git LFS：
- 大文件不直接存到 Git 对象数据库
- 而是存到 GitHub 的 LFS 服务器
- Git 仓库里只存一个指针文件
这算是 GitHub 对 Git 原生缺陷的一个补丁式扩展。
8. GitHub Codespaces / GitHub.dev
直接在浏览器里编辑代码、运行开发环境——这和 Git 的”本地工作流”理念已经相去甚远了。Git 假设你在本地有完整的文件系统和工具链，GitHub 则试图把一切都搬到云端。
总结：GitHub 到底”扩展”了什么？
可以把 Git 和 GitHub 的关系理解为：
Git = 分布式版本控制协议（底层）
GitHub = 基于 Git 的协作平台 + 项目管理工具 + 社交网络（上层）
GitHub 引入的特性大致分为几类：
| 类别 | 例子 | 目的 |
|---|---|---|
| 协作流程 | PR、Fork、Review | 解决开源/大团队权限和审查问题 |
| 项目管理 | Issues、Projects、Milestones | 把代码和任务管理绑定 |
| 自动化 | Actions、Webhooks、Apps | 构建 CI/CD 生态 |
| 社交功能 | @提及、Emoji、Reactions | 降低沟通门槛 |
| 存储扩展 | LFS、Packages | 弥补 Git 原生不适合的场景 |
最后说一句：这些”不一致”不一定是坏事。Git 的设计哲学是”简单、灵活、去中心化”，而 GitHub 的设计哲学是”让协作尽可能低门槛”。两者目标不同，所以产生了这些差异。很多开发者其实没用过纯 Git 的工作流，他们的”Git 经验”本质上大部分是”GitHub 经验”——这也算是一种有趣的认知偏移吧 😄
发表回复