HN 启动：Diversion（YC S22）— 云原生 Git 替代方案

Hacker News 讨论 ↗

一家获得 YC 支持、将 Diversion 推广为“云原生 Git 替代方案”的初创公司引发了开发者们的分歧反应。许多人同意 Git 在 UX、大型二进制资产处理，以及对游戏开发和其他媒体密集型工作流的适配性方面确实存在空白，但也批评 Diversion 以“Git 批判”为卖点、云端中心化且只能云部署的设计，以及缺乏开源或自托管选项，这些都构成了重大的信任与采用障碍。讨论最终形成的共识是：版本控制模型确实还有创新空间——尤其是在大型资产和非编码用户场景中——但成功将取决于它能否清晰地区分于 Git/Perforce、提供有说服力的离线与安全方案，以及对核心技术建立可信的治理方式。

定位与目标市场

  • 许多人认为，Diversion 实际上是在与 Git 托管服务以及 Perforce/Plastic 竞争，而不是与 Git 本身竞争。
  • 有人强烈建议将宣传重点放在游戏工作室、大型二进制文件以及非程序员工作流上，而不是“Git 很糟糕”。
  • 一些人认为，它作为更简单、云优先的 Perforce 替代方案，尤其适合中小型游戏工作室和创意团队，具有潜力。

Git：批评与 دفاع

  • 批评：
    • Git 在概念上很复杂，对非专家来说容易出错；像 push --force 和 reset --hard 这样的命令被视为“脚枪”。
    • 对非编码人员（艺术家、数据科学家等）的用户体验很差。
    • 对大型二进制文件和超大仓库的原生支持薄弱；Git LFS 在大规模场景下被认为笨拙且脆弱。
  • 辩护：
    • 由于 reflog 和分布式克隆，真正的数据丢失很难发生；“毁掉一个月工作”的说法受到广泛质疑，后来也有所缓和。
    • 许多问题被归因于配置不当、培训不足或工作流糟糕，而不是 Git 本身。
    • 现有功能（浅克隆、过滤器、fsmonitor、monorepo 工具链）缓解了一些可扩展性方面的担忧。

云原生、中心化与离线工作

  • Diversion 的设计（无服务器、REST API、始终在云中的状态）因其可扩展性、实时同步以及更容易与 CI/云开发集成而受到称赞。
  • 批评者将“云原生”视为：
    • 从可离线工作的分布式 VCS 退步。
    • 存在单点故障风险，并且不适合网络不稳定的环境（远程办公、飞机上、某些地区）。
    • 可能造成供应商锁定，尤其是依赖 AWS，而且对有严格本地部署/安全要求的工作室很不友好。

安全、开放性与信任

  • 数据在传输中和静态存储时都加密，但不是端到端加密；有些人认为这足以成为处理敏感代码时的阻碍。
  • 许多人坚持不会把核心源代码管理交给一家封闭、纯云端的初创公司；因此强烈要求开源（最好是 copyleft）并支持自托管/私有云。

期望的功能与建议

  • 大家强烈关注以下能力：
    • 一流的大型二进制支持、文件锁定（尤其是跨分支）、部分检出，以及对大仓库的快速操作。
    • 更好的 GUI 和针对非专家的“护栏”、更有主见的工作流，以及相较 Git 更简化的概念。
    • 更丰富的集成：适合 CI 的 CLI、语义/AST 级 diff、集成式 hooks、补丁堆叠，以及更广泛的文档/配置版本管理。
  • 总体语气：对当前的宣传方式和信任模型持怀疑态度，但也清楚地认识到，VCS——尤其是面向二进制文件和非开发者——仍然是一个值得解决的未解问题。