跳转至

Pygit 服务端

这个项目支持一个自建的 .pygit 专用服务端，对应远端 URL 形式：

pygit://host:port

这件事要特别说清楚：
它不是官方 git daemon，也不是官方 Git wire protocol 的完整复现。

为什么要做自建服务端

项目的目标之一，是让仓库不只在本地单机上转，还能：

  • clone；
  • fetch；
  • push；
  • 在两端之间传输对象和 refs。

如果完全不做服务端，项目对“分布式 Git”这一部分的教学会不完整。
但如果一上来就追官方所有网络协议，复杂度又会急剧爆炸。

所以做一个 专用、可控、可教学的 pygit 服务端 是合理取舍。

这个服务端解决什么问题

它主要解决：

  • 两端如何发现对象差异；
  • 如何传输 pack 数据；
  • 如何更新远端 refs；
  • 如何让本地与远端形成真正的同步闭环。

这意味着项目已经不只是“本地版本控制练习”，而是开始真正处理分布式仓库同步。

为什么不直接宣称自己实现了官方 Git 远端

因为那样不诚实。
官方 Git 的网络协议、生态兼容性、托管平台适配都比一个教学型项目复杂得多。

这个项目明确边界：

  • 支持本地路径远端；
  • 支持自建 .pygit 专用 TCP 服务端；
  • 不声称支持 GitHub、SSH Git、HTTP Git 或官方 Git wire protocol。

这种边界表达方式更干净，也更适合后续维护。

这部分的教学价值

即使不是官方协议，这一层依然很有价值。
因为读者仍然能学到：

  • 远端同步的最小闭环长什么样；
  • clone / fetch / push 依赖哪些核心信息；
  • pack 在传输中扮演什么角色；
  • ref 更新为什么需要非快进保护；
  • 一个“够用、清楚、可讲解”的远端协议应该怎么设计。

对于教学项目来说，这已经是非常实在的收获了。