Hva er GitHub? Versjonskontroll for ikke-utviklere

GitHub er en nettside som lagrer koden til programvareprosjekter sammen med hele historikken, slik at du kan se hver endring, angre feil og jobbe på samme prosjekt sammen med andre. Den er bygget på Git, gratis programvare som registrerer øyeblikksbilder av et prosjekts filer over tid. Git er verktøyet som holder historikken; GitHub er det nettbaserte hjemmet der historikken deles, sikkerhetskopieres og diskuteres.

Hvis du bygger med AI, handler GitHub først og fremst om to ting: å eie en kopi av koden din utenfor verktøyet du bygde den i, og å overlevere den til en utvikler i formatet de allerede jobber med.

Hvorfor det betyr noe når du bygger med AI

En AI-appbygger skriver og endrer mye kode raskt, og ikke alle endringer er forbedringer. Versjonskontroll er måten du holder det trygt på.

• Angre med trygghet. Hver lagret endring er et øyeblikksbilde. Hvis AI-en ødelegger noe, går du tilbake til den siste gode versjonen.
• Eierskap. Kode i din egen GitHub-konto forblir din hvis du bytter verktøy, slutter å betale for ett, eller vil ha en second opinion.
• Samarbeid med utviklere. Nesten alle utviklere bruker Git daglig. Et repositorium lar dem gjennomgå det AI-en skrev, rette det og sende endringer tilbake.
• Deploy andre steder. Mange hostingplattformer kan deploye rett fra et GitHub-repositorium.

En hverdagslig sammenligning: endringsspor pluss en delt mappe

Tenk deg et dokument med endringsspor påslått, lagret i en delt mappe.

• Git er endringssporingen: hver redigering registreres, med hvem som gjorde den, når og hvorfor, og du kan gå tilbake til hvilken som helst versjon.
• GitHub er den delte mappen: dokumentet ligger på nett, andre kan få en kopi, og det finnes et sted å kommentere og godkjenne.
• En branch er som å lagre en kopi kalt «utkast — ny prisseksjon» slik at du kan eksperimentere uten å røre versjonen alle er avhengige av. Hvis eksperimentet fungerer, flettes det tilbake med merge.

Forskjellen fra et dokument er omfanget. En app er hundrevis av filer, og Git sporer dem alle sammen, så et øyeblikksbilde er tilstanden til hele prosjektet på én gang.

Git- og GitHub-begreper du kommer til å møte

To poeng er verdt å understreke. For det første er Git-historikk permanent i utgangspunktet: hvis et passord er committet og pushet, fjerner du det ikke fra historikken ved å slette det i en senere commit. For det andre er en commit bare så nyttig som meldingen sin. «Fiks dobbeltbooking når to personer booker samtidig» hjelper deg senere; «oppdatert» gjør ikke det.

Et konkret eksempel: å overlevere en AI-bygget app til en frilanser

Du har bygget en kundeportal med en AI-appbygger. Den fungerer, men du vil at en frilansutvikler skal legge til en krevende integrasjon med regnskapsprogrammet ditt.

1. Koble prosjektet til et nytt privat GitHub-repositorium og push. Repositoriet inneholder nå koden og historikken.
2. Sjekk hva som ligger der. Åpne repositoriet på GitHub. Det skal ikke finnes noen .env-fil og ingen API-nøkler i koden. Hemmeligheter holdes i plattformens innstillinger og deles med frilanseren separat, hvis i det hele tatt — se miljøvariabler og hemmeligheter.
3. Inviter frilanseren som samarbeidspartner på det repositoriet, og ingen andre steder.
4. De jobber på en branch som for eksempel heter regnskapssynk, committer underveis og åpner en pull request når de er ferdige.
5. Du gjennomgår pull requesten. Selv uten å lese kode kan du lese beskrivelsen, se hvilke filer som er endret og stille spørsmål i kommentarene.
6. Flett når du er fornøyd, og pull deretter endringene tilbake til appbyggeren, slik at du og AI-en fortsetter fra den nye versjonen.

Underveis kan du se nøyaktig hva som er endret og angre det om nødvendig. Det er hele verdien av versjonskontroll i én arbeidsflyt. Hvis du vurderer om du i det hele tatt skal hente inn en utvikler, se hire a developer eller bygg med AI.

Vanlige feil og misforståelser

• «GitHub og Git er det samme.» Git fungerer uten GitHub; alternativer som GitLab og Bitbucket er også vert for Git-repositorier.
• «GitHub kjører appen min.» GitHub lagrer kode. Å kjøre den for publikum er webhosting, en egen tjeneste (selv om noen hostingtjenester deployer fra GitHub).
• Å committe hemmeligheter. Den mest skadelige og vanligste feilen. Bruk .gitignore for .env-filer, og bytt ut alle nøkler som noen gang er pushet.
• Bare én branch og ingen meldinger. Greit for solo-eksperimenter, men gi commits tydelige meldinger og bruk branches for alt som er risikabelt.
• Redigere på to steder samtidig. Hvis du endrer kode i GitHub og i AI-appbyggeren uten å hente endringer imellom, får du konflikter. Velg ett sted å redigere om gangen, og synkroniser før du bytter.
• Tro at et privat repositorium er en sikkerhetskopi av alt. Det inneholder kode, ikke innholdet i databasen din eller opplastede filer. Disse trenger sine egne sikkerhetskopier.

Hva du bør be AI-appbyggeren om

• «Legg til en .gitignore som ekskluderer .env, avhengighetsmapper og byggeoutput.»
• «Skriv en README som forklarer hvordan man installerer, hvilke miljøvariabler som trengs (kun navn) og hvordan appen kjøres.»
• «Legg til en .env.example med alle variabelnavn og ingen ekte verdier.»
• «Bruk tydelige, beskrivende commit-meldinger for hver endring.»

Disse fire forespørslene gir et repositorium en utvikler kan sette seg inn i på få minutter. For å flytte appen til dine egne servere, se hvordan eksportere og self-hoste en AI-bygget app, og for å herde den før ekte brukere, ta en AI-prototype til produksjon.

GitHub og Mythex

Mythex lagrer historikk for deg på alle planer: etter hver vellykkede agenttur tar den et checkpoint, som er et Git-øyeblikksbilde du kan gå tilbake til. På Pro kan du koble til GitHub og pushe eller pulle prosjektet mot ditt eget repositorium, eller laste ned hele prosjektet som et arkiv; hemmeligheter og installerte avhengigheter er utelatt fra eksporten. GitHub her brukes til å synkronisere kode, ikke til å logge inn i Mythex. Se GitHub, eksport og import i dokumentasjonen, og prissiden for hva hver plan inkluderer.

Spørsmål