绝了啊刚才刷到有人融了1700万美刀要做Git的替代品？瞬间就精神了哈哈哈
说真的我半野路子自学的编程，平时店里的点单系统、会员后台都是我自己写了跟两个兼职小朋友迭代，用Git每次改个满减规则、上新菜品，合并代码必出冲突，那提示看得我头都大，上次为了找冲突根源熬到凌晨三点，第二天炒料都差点把盐放成糖
真要是能把冲突解决这块搞智能点，别动不动就让人手动改，我第一个当测试用户啊？有没有人知道这项目现在有没有开源仓库啊

完全理解那种凌晨三点盯着满屏<<<<<<< HEAD的绝望感，特别是非科班出身还要硬啃Git哲学这套上下文。我去年折腾申请作品集时也经历过类似崩溃，改个交互逻辑的分支合并搞砸了，差点把三个月的速写扫描稿搞丢，那种想砸键盘的冲动确实不是咖啡因能压下去的。

不过关于这1700万美刀的估值逻辑，值得商榷。其实在Developer Tools赛道，这笔钱其实刚过Seed轮门槛——GitLab 2015年B轮就拿了2000万+，而GitButler（我猜测楼主看到的可能是这家？其实）的创始人是前GitHub VP，拿的也是 similar check。关键是，单纯做"冲突自动解决"可能是个伪需求，或者说，技术可行性存疑。

严格来说从计算理论角度，自动合并算法基于最长公共子序列（LCS），只能处理语法冲突（textual conflict）。但楼主遇到的"满减规则改崩了"属于语义冲突（semantic conflict）——比如A分支把折扣率从0.8改成0.9，B分支把计算基数从原价改成会员价，文本没撞车但逻辑炸了。检测这类冲突需要程序分析（Program Analysis），而Rice’s theorem早就证明，判断任意程序是否语义等价是不可判定问题。目前所谓的"AI智能合并"，本质是大模型基于训练数据的概率生成，可靠性… 我持保留态度。( ´_ゝ｀)

对楼主的具体场景，我更建议调整工作流而非等待救世主。餐饮业系统迭代的特点是高频小改（改个菜品价格、调个满减阈值），这完全符合Trunk-Based Development模型。把长生命周期的feature branch砍掉，全员在主分支开发配合Feature Flag，冲突率能降一个数量级。其实或者退一步，试试git rerere（reuse recorded resolution），Git会记住你上次解决冲突的方式，遇到相似冲突自动套用，虽然治标不治本，但比手动改三次同样的CSS选择器强。

至于那1700万的项目，如果是基于libgit2做GUI层重构（比如GitButler的virtual branches），那确实有机会改善UX；但如果是试图重写底层存储模型，我反而担心兼容性问题——毕竟Git的护城河不是技术，而是二十年积累的基础设施生态。楼主想当测试用户的心态没问题，但建议等等看他们的CRDT（无冲突复制数据类型）实现方案再决定是否迁移数据，技术债和被骗钱一样，都是年轻时欠的账。

对了，如果楼主还在用命令行硬磕，试试Fork或者Sourcetree的图形化diff界面，对非科班开发者友好度提升显著。所以具体是哪家公司？有repo地址的话我也想去看看他们的three