git commit надсилає весь індекс, а не лише додані вами шляхи

Технічний директор Vodou Чад Пріст описав на dev.to два випадки, коли агентські сесії в одному checkout закомітили чужі зміни.

Вісім шляхів додано, двадцять файлів змінено

9 вересня 2026 року одна сесія в його репозиторії додала до індексу вісім шляхів, усі в каталозі gateway MCP-servers/Vodou-Console/, і виконала git commit. Git відповів: "20 files changed". Решта дванадцять файлів належали іншій сесії в тому самому checkout, яка вже мала в індексі тринадцять файлів, серед них тестовий фікстур на 466 рядків і значна частина рушія.

Це був не перший випадок. 28 липня 2026 року сесія додала три шляхи для функції lease, а паралельна сесія виконала git add у проміжку між її add і commit: коміт захопив 185 рядків із демона рушія, чотири файли в MCP-servers/brain/ та scripts/build-server-bundle.sh.

Чому додавання конкретних шляхів не рятує

Тодішнє правило Пріста було простим: додавати лише явні шляхи й ніколи не запускати git add -A. Він визнає, що майже місяць довіряв цьому правилу і помилявся: воно впорядковує вибір одного учасника, але не змінює того, що читає коміт.

git commit без аргументів комітить не те, що ви додали, а індекс. Індекс у worktree рівно один, у файлі .git/index, і кожна сесія читає та пише той самий файл. Тому окремий git add є одним записом у буфер, до якого пишуть і інші процеси. У липні сусідній процес писав у його вікні; у вересні робота сусіда вже була в індексі до старту сесії.

Два виправлення і межі ізоляції

Якщо прибрати Git, збій виглядає так: кілька процесів ділять одне змінне staging-середовище, а крок публікації знімає знімок усього середовища, а не лише оголошених входів свого процесу. Пріст бачить це, зокрема, в паралельних агентах для коду зі спільним worktree.

Перше виправлення — git commit --only зі списком шляхів: він комітить робочу версію лише названих шляхів. Коли два агенти редагували один файл, цього не досить, і він перейшов на приватний індекс: GIT_INDEX_FILE=/tmp/agent-a.index, далі git read-tree HEAD і git apply --cached. Окремий worktree на кожного агента — стандартна порада, але вона не підійшла репозиторію, де агенти редагують одну працюючу систему і мають бачити чужі зміни наживо.

Після коміту з приватним індексом git status застаріває й показує видалення файлів, які вже є в HEAD, тому він перевіряє через git cat-file -e HEAD:path. Висновок для будь-якої системи з кількома письменниками: дивіться, що читає крок публікації, а не те, що ви додали.