问 HN：我们能做得比 Git 更好的版本控制吗？

Hacker News 讨论 ↗

Git 作为版本控制系统的主导地位广受认可，但许多工程师认为它远非理想，尤其是在可用性、处理大型二进制资源以及支持超大 monorepo 方面。评论者提到 Fossil、Mercurial、Perforce、Pijul、Jujutsu 和 Sapling 等替代方案，以及构建在 Git 之上的 UI 层和工具，作为更好工作流和模型可能存在的证据。普遍观点是，网络效应和 GitHub 生态使得短期内彻底替代 Git 的可能性不大，因此大多数实际创新都集中在改进界面、更智能的合并，以及面向非代码资源的专用系统上，而不是完全放弃 Git。

关于 Git 的总体看法

  • 许多人认为 Git “够用”，而且由于无处不在和生态完善，可能会长期占据主导地位，但这并不是因为它是理想方案。
  • 另一些人则认为它远未解决所有问题：界面令人困惑、默认设置不佳，而且存在一些真正的架构性限制。
  • 一些评论指出，Git 取代了更糟糕的系统（RCS/CVS/SVN），解决了重大问题，但如今它本身看起来已经过时。

UX、心智模型与学习曲线

  • 反复出现的抱怨集中在令人困惑的概念和命令上：commit vs push vs pull vs fetch、暂存区、rebase、reflog 等。
  • 有人希望有一个更简单的“简单模式”，只保留一小组安全的命令（类似“保存 / 更新”风格），再提供一个用于高级操作的“专家模式”。
  • 这里存在一种张力：一边是“工具就是给专业人士用的，复杂没问题”，另一边是“糟糕的 UX 会浪费时间，而且没有正当理由”。
  • 图形界面和更高层的工具（IDE、桌面应用、TUI 前端、像 Graphite、Magit 等封装）被认为是驯服 Git 的有效方式。

技术与架构痛点

  • 大文件和二进制资源：Git LFS 被认为笨重且脆弱；游戏开发和 CAD 工作流通常更偏好 Perforce 或 SVN。
  • 超大型 monorepo：在状态扫描、历史体积以及大量文件方面存在性能问题；常见的变通方案包括虚拟文件系统、稀疏/部分克隆，以及供应商自带工具。
  • 冲突解决：当前的合并算法被认为“快但很笨”；对冲突的建模有限（没有把“冲突状态”作为一等公民）、重命名处理困难，而且缺乏语义理解。
  • 存储模型：基于 blob 快照 vs 基于补丁；一些人认为基于补丁的系统（Darcs、Pijul）能带来更好的合并和历史推理能力。

替代方案与新系统

  • 经常被提及的有：Fossil（集成 issue/wiki、不可变历史）、Mercurial 及其衍生物（Sapling、Google 内部系统）、Darcs、Pijul、Jujutsu、Perforce，以及特定领域工具（例如用于超大 AI 数据集的 Oxen）。
  • 一些新工具在存储/协议层面仍与 Git 兼容，同时提供新的 UI 或语义，被认为比彻底切换更容易被采用。

托管、中心化与网络效应

  • Git 的主导地位与 GitHub 及类似代码托管平台紧密相关；离开 GitHub 之后，可发现性和贡献都会受到影响。
  • GitLab、Forgejo/Gitea、SourceHut、Codeberg 和 Fossil 托管等替代方案都存在，但难以对抗网络效应。
  • 代码托管平台之间的联邦互通被提及为一种可能降低锁定效应的方法。

未来方向

  • 提出的想法包括：语义化 diff/merge、基于 AST 的代码存储、将分支历史作为一等对象、更好的物理历史跟踪、与编辑器集成的移动追踪，以及更偏中心化优先的工作流。
  • 目前尚不清楚这些方向中是否有任何一个能积累足够动力取代 Git；在短期内，最现实的路径似乎是在 Git 之上叠加改进层。