Vibekoding i team: 3 regler for ett felles repo

3 vibekodere, 1 repo, 0 kaos: reglene og vår CLAUDE.md

En AI agent kan skrive to hundre linjer på et minutt. Uten regler går én dårlig prompt rett ut til kundene dine. Med disse tre reglene kan tre personer jobbe i ett repo med Claude Code, mens nettsiden kundene bruker, forblir trygg.

Del 1 åpen med konto Hele programmet 7 moduler Tid Rundt 2 timer for del 1

Dette får du

Oppsettet av brancher: beskyttet main, develop og én branch per oppgave

Malen vår for CLAUDE.md med reglene for teamet, klar til å kopieres

Worktrees, så Claude hos hver utvikler jobber i sin egen kopi av repoet

En prompt for review av hver pull request

Hvorfor AI gjør regler i teamet viktigere

Med AI skriver hver utvikler mindre og endrer mer. Det er flott, helt til tre agenter redigerer de samme filene, eller én push med halvtestet kode havner på nettsiden kundene bruker. Problemet er ikke agenten. Problemet er et repo uten regler.

Først to ord. main er grenen (branch) med det som er live akkurat nå. develop er der alt nytt havner først og testes på en stagingkopi av nettsiden.

Regel 1. To brancher som aldri blandes

main er det som er live. develop er der alt testes først. Ingen pusher noen gang til main. Kode kommer til main først når den virker på stagingkopien.

main

develop

feature/TASK-42

Oppgavebrancher starter fra develop og kommer tilbake gjennom en pull request. Bare en testet develop går inn i main.

Regel 2. Én oppgave, én branch, én pull request

Hver oppgave får sin egen branch fra develop, med navnet feature/TASK-number-short-name. Oppgavetavlen vår lager det navnet automatisk, og hver oppgave lenker til sin pull request, så du alltid ser hva som venter på review.

Og Claude hos hver utvikler får sin egen worktree: en egen kopi av repoet, sjekket ut på sin egen branch. To agenter redigerer aldri de samme filene.

Regel 3. Én felles CLAUDE.md og review før merge

Reglene for teamet ligger i CLAUDE.md i roten av repoet. Claude leser filen ved starten av hver økt, så alle agentene i teamet følger de samme reglene. Claude gjør review av hver pull request. Et menneske merger. Hemmeligheter havner aldri i repoet.

Slik leverer tre personer raskt, og nettsiden kundene bruker, forblir trygg.

Sett opp repoet for tre utviklere

Dette går del 1 gjennom

Prompten for oppsettet
Malen for CLAUDE.md
Én Claude per utvikler: worktrees
Review før merge
Release til main

Lag en konto for å åpne del 1

Skriv inn e-postadressen din og klikk på aktiveringslenken vi sender deg. Del 1 åpner med en gang, uten kostnad.

Felles repo, hele programmet

Del 1 gir deg en første versjon som virker. Hele programmet tar den helt frem til et oppsett du kan bruke hver dag.

Fra oppgavetavle til branchBranchnavn fra oppgavenumre, og hver oppgave koblet til sin pull request.

Staging for developAutomatisk deploy av develop til en testkopi av nettsiden.

Sjekker før reviewTester, bygg og søk etter hemmeligheter i hver pull request.

Konflikter uten panikkOppdater en oppgavebranch fra develop og løs konflikter sammen med Claude.

Release og tilbakerullingPull requests for release, tagger og rask tilbakerulling når noe går i stykker.

Hemmeligheter.env holdes utenfor git, krypterte sikkerhetskopier og hva du gjør etter en lekkasje.

Første dag for en ny utviklerTilgang, CLAUDE.md, sjekklisten og en første liten oppgave.

PrisPrisen vises her før betalingen åpner.

Kjøp hele programmet

Kilder

Vanlige arbeidsflyter: worktrees, Claude Code docscode.claude.com/docs/en/common-workflows

Worktrees, Claude Code docscode.claude.com/docs/en/worktrees

Minne og CLAUDE.md, Claude Code docscode.claude.com/docs/en/memory

Om beskyttede brancher, GitHub Docsdocs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

Spørsmål og svar

Trenger vi GitHub for dette?

Nei. Reglene fungerer med alle tjenester som drifter Git. Kommandoene i denne guiden bruker GitHub og kommandolinjeverktøyet gh, fordi beskyttelse av brancher og pull requests settes opp der med noen få linjer. Bruker dere en annen tjeneste, ser kommandoene annerledes ut, men reglene er de samme.

Hvorfor ikke la Claude merge pull requestene?

Fordi en person må stå ansvarlig for det som går live. Claude gjør review, forklarer og retter. Et menneske leser reviewen og trykker på merge. Den ene regelen hindrer en selvsikker agent i å sende sin egen feil rett ut i produksjon.

Holder det med én godkjent review når vi er tre?

For et lite team er én godkjent review pluss reviewen fra Claude en god balanse mellom fart og sikkerhet. Når teamet vokser, eller når koden håndterer betalinger eller personopplysninger, bør du øke kravet til to godkjente reviews før en pull request kan merges.

Hva skjer hvis noen pusher til main ved en feil?

Når beskyttelsen av main er slått på og også gjelder administratorer, avviser GitHub pushen, så ingenting havner i produksjon. Utvikleren åpner i stedet en pull request inn i develop, og det er akkurat den vanen du vil at hele teamet skal ha.

Flere guider til Claude Code

EVARundt 3 timer for del 1

Eva: en AI annonsespesialist for Meta

Steg for steg til Eva, en AI annonsespesialist i teamchatten: rapporter fra annonsene i Meta, kostnad per kvalifisert lead og regler som en spesialist.

Del 1: åpen med kontoHele programmet: 7 moduler

DASHBOARDRundt 3 timer for del 1

Et dashbord for Facebook annonser i kroner

Bygg et dashbord for Facebook annonser på én lenke med Claude Code: forbruk, leads, kostnad per lead og per kvalifisert lead i kroner, med tokenet på serveren.

Del 1: åpen med kontoHele programmet: 6 moduler

FACTS5 minutter å lese, del 1 rundt 1 time

Opus 5.5: fakta og myter, med kilder

Er Opus 5.5 virkelig med i Free-planen? Når kom den ut? Fire myter og seks fakta om Claude Opus 5.5, hver sjekket på Anthropics egne sider.