Lokal merge-kø serialiserer parallelle Claude Code-agenter og koster null skyminutter

Rundt 15 commits i timen, og opptil 90 i døgnet. Det er tempoet utvikleren bak claude-code-merge-queue oppgir fra et sideprosjekt der parallelle Claude Code-agenter lander kode i samme gren. Taket settes av testsuiten din: FIFO-låsen holdes gjennom hele checkCommand, så en suite på tre til fire minutter presser deg godt under 20 landinger i timen. Pakken ble lagt ut som Show HN 30. juli og står med 105 stjerner på GitHub.

Verktøyet installeres som dev-avhengighet og setter opp seg selv med én init-kommando. Hver agent får en nummerert bane: grenen lane/1, worktreet ved siden av repoet, og dev-server-port 3000 pluss banenummeret, så to agenter aldri slåss om samme port. init skriver også en WorktreeCreate-hook inn i .claude/settings.json, legger land, sync og promote i package.json, og lager eller utvider en pre-push-hook.

Det er pre-push-hooken som gjør ordningen bindende. En direkte git push mot integrasjonsgrenen avvises, med den faktiske kommandoen du skal kjøre i stedet, og samme hook kjører checkCommand før en landing slipper gjennom. Er checkCommand ikke satt, feiler alle push som standard. Nødutgangen er én miljøvariabel foran push-kommandoen, og README-en er tydelig på at det er en konvensjon mot uhell, ikke en garanti mot en agent som setter variabelen selv.

Sammenlignet med GitHubs egen merge queue er poenget prisen og tilgangen: GitHubs versjon krever pull requests og er forbeholdt Enterprise Cloud på private repoer, mens denne kjører på maskinen din uten Actions-minutter.

«Jeg leser definitivt ikke koden når 90 commits går inn på en dag.» — funador, utvikleren bak claude-code-merge-queue

Han beskriver i stedet en lokal suite med enhets-, arkitektur-, e2e-, bygg-, lint- og typesjekk-tester som kjører ved merge til dev og igjen ved merge til main, pluss e2e-tester etter push til prod som ruller tilbake automatisk ved regresjon. Pull requests bruker han ikke i denne flyten, og han fraråder den for team: resultatet ville blitt én gigantisk PR ingen vil lese.

README-en lister begrensningene selv, og det er den beste grunnen til å lese den før du installerer. Ingen mennesker vurderer koden før den lander, checkCommand er eneste port, og en ekte testsuite og et ekko-kall ser identiske ut for verktøyet. Låsene er krasjsikre via PID-liveness i stedet for timeout, så en drept prosess etterlater ingen stående lås. Køen ligger i lokal midlertidig lagring og fungerer derfor bare på én maskin: to maskiner som lander samtidig får bare gits vanlige avvisning. Rebase-konflikter avbrytes alltid, aldri gjettes på.

I tråden dukket det opp et alternativ som fjerner problemet i stedet for å køe det.

«Jeg har det langt bedre med jj og ett arbeidsområde per subagent enn jeg hadde med git og worktrees.» — barrkel, i Hacker News-tråden

Hva bør du gjøre?

1. Sett checkCommand til den suiten du faktisk stoler på før du slipper agenter løs mot integrasjonsgrenen. Verktøyet skiller ikke ekte tester fra en kommando som alltid returnerer null.
2. Mål hvor lenge suiten kjører: den tiden er et direkte tak på hvor mange landinger du får per time, og det er den knappen du skal skru på først.
3. Hold promote manuell, slik pakken anbefaler, og la aldri kommandoen stå i instruksjonene til en agent.