git commit მთელ ინდექსს აგზავნის, არა მხოლოდ დამატებულ ფაილებს

Vodou-ის CTO-მ, Chad Priest-მა, dev.to-ზე ორი შემთხვევა აღწერა, როცა ერთ checkout-ზე მომუშავე აგენტებმა ერთმანეთის ცვლილებები ჩააკომიტეს.

რვა ბილიკი და 20 შეცვლილი ფაილი

Vodou-ის რეპოზიტორში მომუშავე აგენტმა სესიამ 2026 წლის 9 სექტემბერს რვა ბილიკი დაამატა, ყველა gateway-ის დირექტორიაში MCP-servers/Vodou-Console/, და git commit გაუშვა. Git-ის პასუხი იყო: „20 ფაილი შეიცვალა“. დანარჩენი 12 ფაილი სხვა სესიას ეკუთვნოდა, რომელსაც ინდექსში უკვე 13 ფაილი ჰქონდა დამატებული, მათ შორის 466 ხაზის ტესტის ფიქსტურა და ძრავის დიდი ნაწილი.

ეს პირველი შემთხვევა არ ყოფილა. 2026 წლის 28 ივლისს ერთმა სესიამ lease-ისთვის სამი ბილიკი დაამატა, პარალელურმა სესიამ კი მის add-სა და commit-ს შორის git add გაუშვა: commit-მა თან წაიღო ძრავის daemon-იდან 185 ხაზი, MCP-servers/brain/-ის ოთხი ფაილი და scripts/build-server-bundle.sh.

რატომ არ კმარა საკუთარი ბილიკების დამატება

იმ დროს Priest-ის წესი იყო: დაამატე მხოლოდ კონკრეტული ბილიკები და არასდროს გამოიყენო git add -A. მან თითქმის ერთი თვე ირწმუნა, რომ ამით პრობლემა დაიხურა, და შეცდა: წესი მხოლოდ არჩევანს აწესრიგებს და არაფერს ცვლის იმაში, თუ რას კითხულობს commit.

git commit არგუმენტების გარეშე აკომიტებს არა იმას, რაც თქვენ დაამატეთ, არამედ ინდექსს. ინდექსი კი ერთია თითო worktree-ზე და მდებარეობს .git/index-ში. იმავე worktree-ის ყველა სესია ამ ფაილს კითხულობს და წერს, ამიტომ ცალკეული git add ერთი ჩანაწერია ბუფერში, რომელშიც სხვა პროცესებიც წერენ. ივლისში მეზობელი პროცესი მისი ფანჯრის დროს წერდა, სექტემბერში კი მეზობლის ნამუშევარი სესიის დაწყებამდე იყო დამატებული.

ორი გამოსავალი და იზოლაციის ფარგლები

Git-ის გარეშე ხარვეზი ასე გამოიყურება: რამდენიმე პროცესი იზიარებს ერთ, ცვალებად staging-სივრცეს, გამოქვეყნების ნაბიჯი კი მთელი სივრცის სნაპშოტს იღებს და არა საკუთარი პროცესის გამოცხადებულ მონაცემებს. Priest ამას ხედავს ერთ worktree-ს გამზიარებელ კოდირების აგენტებშიც.

პირველი გამოსავალია git commit --only ბილიკების ჩამონათვალით, რომელიც მხოლოდ დასახელებული ბილიკების სამუშაო ვერსიას აკომიტებს. თუ ორივე აგენტი ერთ ფაილს შეცვლის, ეს არ კმარა, და Priest პირად ინდექსზე გადავიდა: GIT_INDEX_FILE=/tmp/agent-a.index, შემდეგ git read-tree HEAD და git apply --cached. თითო აგენტისთვის ცალკე worktree სტანდარტული რჩევაა, თუმცა ამ რეპოზიტორს არ მოერგო, სადაც აგენტები ერთ მოქმედ სისტემას არედაქტირებენ და სხვების ცვლილებები ცოცხლად უნდა ნახონ.

პირადი ინდექსით კომიტის შემდეგ git status მოძველებულს ხდება და იმ ფაილების წაშლას აჩვენებს, რომლებიც HEAD-ში უკვე არის, ამიტომ Priest git cat-file-ით ამოწმებს, ნამდვილად არსებობს თუ არა ფაილი. საბოლოო წესი კი ასეთია: შეხედე, რას კითხულობს გამოქვეყნების ნაბიჯი და არა იმას, რაც შენ დაამატე.