Git-bug：嵌入 Git 的分布式、离线优先 bug 跟踪器

整体反响与概念

• 许多人觉得把分布式、离线优先的 issue 跟踪器放进 Git 里这个想法很有吸引力，尤其适合小团队和本地优先的工作流。
• 人们喜欢 issue 可以跟着仓库走、可以版本化，并且独立于任何特定的 SaaS forge。
• 有人认为 ticket 是代码历史不可分割的一部分（尤其是已解决的 bug），因此与代码共置很有吸引力。

命名与范围（“bug” vs “everything”）

• 有几个人指出，“git bug”这个名字听起来会限制在 feature request、PR 和其他工作流上。
• 也有人指出，许多历史上的跟踪器把 “bug” 用来指代所有 issue 类型，而且实践中一直没问题。
• 目前的 CLI 命名（例如，可能出现的 git bug bug vs git bug pr）被认为有点别扭，但还不至于成为阻碍。

分布式 issue 跟踪的挑战

• 之前的分布式跟踪器尝试往往失败，主要卡在 merge/conflict 处理以及跨分支协作上。
• 讨论的一个焦点是把 issue 绑定到分支还是放在共享空间；分支专属 issue 精度更高，但会让共享状态不明显。

数据模型、CRDT 与 Git 集成

• 这个项目刻意避免让 ticket 直接面对原始 Git merge 冲突，而是使用 CRDT 风格的操作。
• 理由是：对于社交交互来说，捕捉用户意图并避免手动冲突解决，比精确合并文本更重要。
• Git 灵活的 refs 命名空间受到称赞；issue 可以与分支/标签并列存在，而不需要改变 Git 核心。

身份与安全模型

• Git 的姓名/邮箱/签名模型被认为对点对点、离线优先的社交系统来说太弱。
• 该项目有自己的身份层，使用公钥，并计划迁移到基于 DID 的基础设施，以便跨仓库共享身份。
• 也有人讨论未来是否还会用这些身份来验证代码提交。

可用性、可访问性与 Web UI

• 有人认为 issue 跟踪器必须对广泛用户可访问；把它绑在 Git/CLI 上可能会把非开发者排除在外。
• 也有人建议，带 OAuth/OIDC（以及可能的联邦标准）的 Web UI 是必需的，这样它看起来就像普通的托管跟踪器，但底层仍然是本地优先。
• 还提议使用桌面应用或 Docker 化的 Web 前端，以减少非技术用户接触 Git 的需求。

网络、SSH 与实现问题

• 需要 SSH agent 才能 push/pull 的 bug 被一些人称为“致命问题”；也有人觉得这只是小问题。
• 争议集中在没有使用系统 SSH，这会破坏复杂的 ~/.ssh/config 配置（ProxyJump、多身份、跳板机）。
• 作者表示，计划改为调用 Git 二进制（或类似方式）作为回退，可能默认就这么做。

工作流功能与限制

• 目前只有二元的 open/closed 状态被认为太有限；人们希望有可配置状态以及可扩展的操作/实体。
• 这个数据模型被设计为：即使添加新的操作/实体，也不会破坏旧客户端。

动机 vs 中心化服务

• 支持者看重不依赖 SaaS、离线速度，以及整个项目自包含。
• 批评者认为，中心化的 Web 跟踪器更适合广泛访问，而且把 bug 生命周期与 Git 历史绑定在一起往往显得牵强。
• 还有一个担忧：为了让非编码者编辑 ticket 而要求 Git 权限（例如 force-push）会破坏既有的角色边界。

变现与生态

• 把这件事做成全职工作被认为很难；卖给企业也被视为不容易。
• 有人建议细分场景：爱好项目、对 LLM 友好的仓库，或者提供带支持的“企业”层级。
• 目前也在积极讨论扩展到 pull request、CI 和类似 forge 的能力。

替代方案与相关项目

• 讨论中提到了多个前人工作和相邻工具：Fossil、其他基于 Git 的跟踪器、审查系统、基于 CRDT 的 metadata forge，以及基于文件的 ticket 系统。
• Fossil 被引用为“VCS + tracker 集成可以很好工作”的证据，不过它的一些强观点（例如不允许重写历史）让部分人难以接受。
• 一些用户更喜欢更简单、基于文本或 JSON 的跟踪器，把它们放在专门的分支或仓库里，主张关注点分离和尽量少的魔法。