从Git灾难到Antigravity：一个广州老码农的版本管理折腾记

上周五晚上十一点，我蹲在荔湾老城区的出租屋里，对着屏幕上一串红色的merge conflict发呆。楼下肠粉店已经收档，而我，一个在广州干了七年开发的老程序员，正在为一个本该十分钟搞定的代码合并熬到怀疑人生。

一、那天晚上的Git惨案

我负责订单状态机，同事阿杰改支付回调，外包老哥动库存扣减。三个人的改动都碰了order_service.py。第三天往develop合并，炸了——十几个冲突文件，order_service.py里冲突块二十多处。有些是变量命名不一致，最离谱的是两个分支各自实现了同一个功能：一个叫get_order_detail，一个叫fetch_order_info，底层逻辑还不一样。我从晚上九点肝到凌晨一点半，合并完跑测试挂了，最后发现库存扣减逻辑在合并时被覆盖，少了一个事务回滚。那一刻脑子里冒出一个念头：这要是考公上岸了，是不是就不用受这个罪了？

二、为什么Git“管”不住代码

Git本身没问题，但它只是一个工具，不替你做决策。复盘那晚的惨案，根因有三个：

第一，分支策略形同虚设。 名义上用Git Flow，但feature分支生命周期太长。阿杰的支付分支拖了五天，期间develop往前走了几十个commit，冲突堆积如山。

第二，代码所有权不清晰。 同一个文件三个人都在改，没有划分模块边界。物理世界里你不会让三个装修队同时刷同一面墙，但代码世界里因为“反正Git能合并”，大家就肆无忌惮。

第三，合并时机靠感觉。 没人规定什么时候必须合并。外包老哥压根不pull develop，直接基于一周前的develop开分支，合的时候跟炸碉堡似的。

那天凌晨我发了个朋友圈：“Git管的是版本，不是人。人才是版本管理里最大的bug。”

三、Docker不是救星，但是解药的一部分

环境不一致恰恰是版本冲突的放大器。 阿杰本地跑Python 3.10，我3.9，外包老哥3.8。他本地跑通推到develop后CI挂了，手动改了requirements.txt锁到老版本，又跟我们的代码冲突了。

后来我花了一个周末把项目全面Docker化：

FROM python:3.10-slim

WORKDIR /app

# 先复制依赖文件，利用Docker层缓存
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 再复制源码
COPY . .

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

CI里加了一步：任何PR合并前，必须用Docker镜像跑完整测试。本地能跑不算数，容器里跑通才算。这堵死了“我本地没问题啊”的万能借口。

四、遇到Antigravity：版本管理的“自动驾驶”尝试

今年年初在V2EX上刷到Google开源的Antigravity——不是替代Git，而是在Git之上加一层智能编排层。它自动做三件事：

第一，冲突预判。 后台持续监控所有活跃分支的改动范围，检测到两个分支在修改同一文件的同一函数时提前预警，而不是等到合并时才炸。

第二，合并策略推荐。 根据改动类型和历史合并成功率，推荐用merge还是rebase，甚至建议先合并哪个分支能最小化冲突。

第三，自动生成合并说明。 分析diff，自动生成合并说明，标注关键变更和风险点。

部署不复杂，它本身跑在Docker里：

docker run -d \
  --name antigravity \
  -p 8080:8080 \
  -v /path/to/repo:/repo \
  -e AG_REPO_PATH=/repo \
  -e AG_GIT_TOKEN=${GIT_TOKEN} \
  antigravity/server:latest

第四天它第一次预警：阿杰的支付分支和我的订单分支在process_payment函数上有重叠改动。我们提前碰了一下，五分钟划清边界——如果没有预警，大概率重演惨案。还有一次它建议我先rebase再合并，理由是“develop在最近24小时内有17个commit，其中3个涉及你正在修改的文件”。我照做了，rebase只花十分钟，冲突两个都是小改。

五、Antigravity不是银弹，但改变了我的认知

用了三个月，最大的感受是：它把版本管理从“事后补救”变成了“事前预防”。传统Git流程是画完了才发现重叠然后开始擦；Antigravity是在你下笔之前就告诉你“这块地方已经有人在画了”。

但也要吐槽：配置文件antigravity.yaml里几十个参数，学习成本不低。预警有时候过于敏感，有一次警告两个分支同文件有冲突风险，结果一个改文件开头的import，一个改末尾的函数，八竿子打不着。这种“狼来了”多了，人会麻木。另外它对小团队来说可能有点重，五个人靠沟通就能解决大部分问题，它的价值在大型团队、跨时区开发场景下才能最大化。

六、一个考公程序员的版本管理哲学

今年七月我报了广东省考，白天写代码，晚上刷行测。但越准备考公，越觉得版本管理的思维在体制内同样适用。体制内最怕“政出多门”“文件打架”——这不就是版本冲突吗？

Antigravity的核心思想——提前发现冲突、建议协调方案、记录决策过程——放在任何需要多人协作的场景都是通用的。我现在写代码会有意识地想：这个改动会不会跟别人撞车？应该提前跟谁沟通？这可能就是程序员经历带给我的：不是具体的技术栈，而是一套处理复杂协作问题的思维框架。

最后的碎碎念

版本管理说白了就是在混乱中建立秩序。Git、Docker还是Antigravity，都在做同一件事：让一群人在同一份代码上协作时，不至于把彼此逼疯。

如果你也在被merge conflict折磨，我的建议是：先把Docker环境统一了，再考虑要不要上Antigravity。工具永远只是辅助，真正重要的是团队的沟通习惯和对代码边界的敬畏。

考公这条路不知道能不能走通，但写代码这些年教会了我怎么在混乱中找秩序——这本事，到哪儿都用得上。