# ERR-20260515-001 — 连发 git push 时本地 tracking ref 漂移导致 remote rejected

**Date**: 2026-05-15
**Tags**: git, concurrent-push, ai-agent-pace
**Severity**: Low（自愈）

## 症状

PR #380 工作流中：
1. 第二次 `git push` 走 `run_in_background=true`（还没回执）
2. 立刻 commit 第三个 patch 并 `git push`
3. 第三次 push 报错：

```
remote: error: cannot lock ref 'refs/heads/feature/...': is at 58f3e6d9 but expected 1d7e4bde
! [remote rejected]   feature/... -> feature/... (failed to update ref)
```

## 根因

git push 用 CAS 风格的原子 ref 更新：本地认为 remote ref 在 X，要求 remote 实际 ref 也在 X，才允许推进到 Y。第二次 push 已成功（remote 推到了 58f3e6d9），但本地 tracking ref `refs/remotes/origin/feature/...` 还停留在 1d7e4bde，因为第二次 push 是后台任务，本地没收到回执前没更新 tracking。第三次 push 时 git CAS 检查发现 remote 实际状态超出本地预期，拒绝。

不是冲突也不是 force-push 问题——只是本地 tracking ref 落后。

## 解法

`git fetch <remote> <branch>` 同步 tracking ref 后重试 `git push`。本次 fetch 后 push 一次就 OK。

也可以等第二次 push 的 background notification（系统会推 task-notification）再发第三次。

## 元教训：AI agent 节奏下别连发后台 push

AI agent 把 push 跑后台并立刻继续做下一件事是常态，但 git push 不是无副作用的——它会改 remote ref 状态，后续 commit + push 必须基于最新 remote ref。规则：

- **一个分支的连续 push 之间，要么等通知再发下一个，要么 push 前 `git fetch` 一次**
- 如果用 background mode 发 push，**不要在通知到来前 commit 新 patch 并 push**
- 多分支并发 push 互不影响（不同 ref），安全
- 这跟 develop/staging fast-forward-only 策略也对齐：FF-only 下任何"远端比本地新"都会拒绝

## 验证

```bash
# 复现：tab1 push（慢），tab2 立刻 commit + push
# 期望：tab2 push 报 "is at X but expected Y"
# 修复：tab2 git fetch && git push 即可
```