我们已筹集 $17M，打造 Git 之后的产品
Source: Hacker News
GitButler 背后的故事
我曾是 GitHub 的联合创始人之一，在过去的 15 年里，见证了 Git 从一个小众的开发者工具演变为几乎所有软件开发的基础设施。这段旅程让我明白，开发者平台之所以成功，是因为它们 消除协作摩擦，让工程师专注于写代码，而不是管理繁琐的事务。
GitButler 在三年前启动，因为我们觉得开发实践已经被迫在 Git 的约束下运行太久。我们想要的工具是 为现代工作流而设计 的，而不是在旧模型上进行改造。
我们的新董事会成员 a16z 的 Peter Levine 与我在 GitButler A 轮融资签约现场。
为什么 Git 需要重新设计
Git 在 过去的 20 年 里解决了关键问题（参见回顾），但如今的环境已经发生了巨大的变化。现在我们在教一大批代理人使用一个为邮件列表发送补丁而构建的工具——这与现代开发的需求相去甚远。
在 GitHub，反复出现的痛点很明显：开发者之所以感到困难，并不是因为他们写不出代码，而是因为 工具、人员以及现在的 AI 代理之间的上下文碎片。真正困难的不是生成变更，而是 在不混乱的情况下组织、审查和集成变更。
旧的模型假设“一个人、一条分支、一个终端、一次线性流程”。在 AI 辅助工具兴起的今天，这一模型已经不再足够。
介绍 GitButler CLI
上周我们发布了 GitButler CLI 的技术预览版。
- 为 GitHub Flow 风格（短生命周期分支、基于主干的工作流）而设计。
- 支持 堆叠分支、并行工作，以及操作的轻松 撤销。
- 提供 组织 与 多任务 变更的命令，使工具对人类、AI 代理和脚本同样有用。
- 可直接在任何已有的 Git 项目中使用，无需迁移。
关键文档
重新思考社交编码
GitHub 通过 fork 和 pull request 推广了 “社交编码”，但许多协作要素仍然碎片化：问题列表、看板、外部聊天群以及会从 Git 历史中消失的 PR 描述。
想象一下，一个 主动帮助构建逻辑清晰、上下文丰富的变更 的版本控制工具，能够实时呈现相关代理交互，并在冲突出现时立即发出警告。设想在一个堆叠在同事分支上的分支上工作，而你们双方都在继续修改这些分支，代理能够实时了解彼此的工作。
这就是我们在 GitButler 正在构建的愿景。此次融资将加速打造 下一代软件开发基础设施——不是 “更好的 Git”，而是软件构建方式的新基石。