If I Could Make My Own GitHub
a day ago
- 当前的代码托管平台如GitHub、GitLab和Gitea都遵循GitHub设定的相同模式，与实际Git使用关联甚少；大多数工作流程都在平台内部进行，而非在客户端。
- Git本是为基于补丁的去中心化内核开发而设计，但大多数用户将其视为一个中心化的拉取/推送系统，由托管平台处理身份认证、审查、CI/CD和发布。
- 拉取请求工作流存在问题：提交顺序经常错乱，修复堆积；反馈应通过平台上的预提交钩子在推送前进行。
- PR审批过于二元化；应该存在‘弱批准’或‘稍后处理’的选项，类似于Gerrit的模式。
- PR过于僵化；并非所有更改都需要四眼审查，尤其是在有LLM辅助的情况下；维护者及低风险更改应绕过严格审查。
- 堆叠式PR应成为一级特性，而非附加功能，因为它们更易于审查和理解。
- 代码托管平台不应试图包揽一切；它应专注于问题追踪和版本控制等核心功能，而不应包含看板或Wiki等易成为维护负担的功能。
- 托管单元应更小、更模块化；一个组织应能通过几台树莓派运行代码托管平台，而无需复杂的部署。
- 本地仓库副本应代表整个仓库状态（包括issue和PR），并允许从本地版本控制系统执行批准PR等操作。
- 鉴于通常可联网，克隆应默认浅层克隆；深层历史应在需要时获取，以减少存储和带宽。
- 操作应签名、固定SHA哈希，并支持离线使用；用户应能将其捆绑到仓库中，并通过类似Dependabot的PR进行更新。
- 理想的代码托管平台将使用现代版本控制系统如JJ，集成浅层克隆和对象存储，并能抵御持续的LLM机器人流量。
- 尽管其他工具零星存在，但尚未有人构建出可完全替代日益恶化的单体式托管平台模式的产品；作者希望致富后能打造一个这样的平台。