git commit-ը ուղարկում է ամբողջ ցուցիչը, ոչ միայն ձեր ավելացրած ուղիները

Vodou-ի տեխնիկական տնօրեն Chad Priest-ը dev.to-ում նկարագրել է երկու դեպք, երբ նույն checkout-ում աշխատող գործակալների սեսիաները commit արեցին միմյանց փոփոխությունները։

Ութ ուղի ավելացվեց, քսան ֆայլ փոխվեց

2026 թվականի սեպտեմբերի 9-ին նրա պահոցում մի գործակալ սեսիա ցուցիչին ավելացրեց ութ ուղի, բոլորը gateway-ի MCP-servers/Vodou-Console/ պանակում, և գործարկեց git commit։ Git-ի պատասխանն էր՝ "20 files changed"։ Մնացած տասներկու ֆայլերը պատկանում էին նույն checkout-ում աշխատող մեկ այլ սեսիայի, որն արդեն ցուցիչում ուներ տասներեք ֆայլ, դրանց թվում 466 տողանոց թեստային fixture և շարժիչի զգալի մասը։

Սա առաջին դեպքը չէր։ 2026 թվականի հուլիսի 28-ին մի սեսիա lease ֆունկցիայի համար ավելացրեց երեք ուղի, իսկ զուգահեռ սեսիան git add գործարկեց դրա add-ի ու commit-ի արանքում. commit-ը ներքաշեց շարժիչի daemon-ից 185 տող, MCP-servers/brain/-ի չորս ֆայլ և scripts/build-server-bundle.sh-ը։

Ինչու բացահայտ ուղիներ ավելացնելը բավարար չէ

Այն ժամանակ Priest-ի կանոնը սա էր՝ ավելացրու միայն հստակ ուղիներ և երբեք չգործարկես git add -A։ Նա ասում է, որ գրեթե մի ամիս վստահում էր այդ կանոնին և սխալվում էր. կանոնը կարգավորում է միայն մեկ մասնակցի ընտրությունը, բայց չի փոխում այն, ինչ կարդում է commit-ը։

Առանց արգումենտների git commit-ը commit է անում ոչ թե այն, ինչ դուք ավելացրել եք, այլ ցուցիչը։ Ցուցիչը մեկն է ամբողջ worktree-ի համար և գտնվում է .git/index-ում. բոլոր սեսիաները կարդում ու գրում են նույն ֆայլը, ուստի առանձին git add-ը մեկ գրառում է բուֆերում, որին գրում են նաև այլ պրոցեսներ։

Երկու լուծում և մեկուսացման սահմանները

Առանց Git-ի խափանումը այսպիսին է՝ մի քանի պրոցեսներ կիսում են մեկ փոփոխվող staging տարածք, իսկ հրապարակման քայլը պատկերում է ամբողջ տարածքը և ոչ թե պրոցեսի հայտարարված մուտքերը։ Priest-ը սա տեսնում է, ի թիվս այլոց, մեկ worktree կիսող զուգահեռ գործակալներում։

Առաջին լուծումը ուղիների ցուցակով git commit --only-ն է, որը commit է անում միայն նշված ուղիների աշխատանքային տարբերակը։ Եթե երկու գործակալ խմբագրել են նույն ֆայլը, նա անցավ մասնավոր ցուցիչի՝ GIT_INDEX_FILE=/tmp/agent-a.index, հետո git read-tree HEAD և git apply --cached։ Յուրաքանչյուր գործակալի համար առանձին worktree-ը ստանդարտ խորհուրդ է, սակայն չհամապատասխանեց այն պահոցին, որտեղ գործակալները խմբագրում են մեկ աշխատող համակարգ և պետք է կենդանի տեսնեն մյուսների փոփոխությունները։

Մասնավոր ցուցիչով commit-ից հետո git status-ը հնանում է և ցույց է տալիս HEAD-ում արդեն եղած ֆայլերի ջնջում, ուստի նա ստուգում է git cat-file -e HEAD:path-ով։ Եզրակացությունը ցանկացած համակարգի համար, որտեղ մեկից ավելի գրող կա՝ նայիր, թե ինչ է կարդում հրապարակման քայլը, այլ ոչ թե այն, ինչ դու ավելացրել ես։