Hvad er GitHub? Versionskontrol for ikke-udviklere

GitHub er et websted, der gemmer koden til softwareprojekter sammen med hele historikken, så du kan se hver ændring, fortryde fejl og arbejde på det samme projekt sammen med andre. Det er bygget på Git, gratis software, der registrerer øjebliksbilleder af et projekts filer over tid. Git er værktøjet, der holder historikken; GitHub er det online hjem, hvor historikken deles, sikkerhedskopieres og diskuteres.

Hvis du bygger med AI, handler GitHub mest om to ting: at eje en kopi af din kode uden for det værktøj, du byggede den i, og at give den til en udvikler i det format, de allerede arbejder med.

Hvorfor det betyder noget, når du bygger med AI

En AI-appbygger skriver og ændrer hurtigt en masse kode, og ikke alle ændringer er forbedringer. Versionskontrol er måden, du holder det sikkert på.

• Fortryd med tryghed. Hver gemt ændring er et øjebliksbillede. Hvis AI'en ødelægger noget, går du tilbage til det sidste gode.
• Ejerskab. Kode i din egen GitHub-konto forbliver din, hvis du skifter værktøj, stopper med at betale for et, eller vil have en second opinion.
• Samarbejde med udviklere. Næsten alle udviklere bruger Git dagligt. Et repository lader dem gennemgå det, AI'en skrev, rette det og sende ændringer tilbage.
• Deployment andre steder. Mange hostingplatforme kan deployere direkte fra et GitHub-repository.

En hverdagsanalogi: sporede ændringer og et delt drev

Tænk på et dokument med sporede ændringer slået til, gemt på et delt drev.

• Git er de sporede ændringer: hver redigering registreres med hvem, hvornår og hvorfor, og du kan rulle tilbage til enhver version.
• GitHub er det delte drev: dokumentet ligger online, andre kan få en kopi, og der er et sted at kommentere og godkende.
• En branch er som at gemme en kopi kaldet „kladde – ny prissektion“, så du kan eksperimentere uden at røre den version, alle er afhængige af. Hvis eksperimentet virker, flettes det tilbage.

Forskellen fra et dokument er omfanget. En app består af hundredvis af filer, og Git sporer dem alle sammen, så et øjebliksbillede er tilstanden for hele projektet på én gang.

Git- og GitHub-begreber, du vil støde på

To punkter er værd at understrege. For det første er Git-historikken permanent by design: hvis en adgangskode bliver committet og pushet, fjerner det ikke den fra historikken at slette den i en senere commit. For det andet er en commit kun så nyttig som sin besked. „Ret dobbeltregistrering ved booking, når to personer booker samtidig“ hjælper dig senere; „opdater“ gør ikke.

Et konkret eksempel: at overdrage en AI-bygget app til en freelancer

Du har bygget en kundeportal med en AI-appbygger. Den virker, men du vil have en freelanceudvikler til at tilføje en besværlig integration med dit regnskabsprogram.

1. Forbind projektet til et nyt, privat GitHub-repository og push. Repositoryet indeholder nu koden og dens historik.
2. Tjek, hvad der ligger i det. Åbn repositoryet på GitHub. Der skal ikke være en .env-fil eller API-nøgler i koden. Hemmeligheder bliver i din platforms indstillinger og deles med freelanceren separat, hvis overhovedet. Se miljøvariabler og hemmeligheder.
3. Inviter freelanceren som medarbejder på netop dette repository.
4. De arbejder på en branch med et navn som accounting-sync, committer undervejs og åbner en pull request, når de er færdige.
5. Du gennemgår pull requesten. Selv uden at læse kode kan du læse beskrivelsen, se hvilke filer der er ændret og stille spørgsmål i kommentarerne.
6. Merge, når du er tilfreds, og derefter pull ændringerne tilbage i din appbygger, så du og AI'en fortsætter fra den nye version.

Undervejs kan du se præcis, hvad der er ændret, og fortryde det, hvis det er nødvendigt. Det er hele værdien ved versionskontrol i ét forløb. Hvis du overvejer, om du overhovedet skal hente en udvikler, så se ansæt en udvikler eller byg med AI.

Almindelige fejl og misforståelser

• „GitHub og Git er det samme.“ Git virker uden GitHub; alternativer som GitLab og Bitbucket hoster også Git-repositories.
• „GitHub kører min app.“ GitHub gemmer kode. At køre den for offentligheden er webhosting, en separat tjeneste (selvom nogle hosts deployer fra GitHub).
• At committe hemmeligheder. Den mest skadelige og mest almindelige fejl. Brug .gitignore til .env-filer, og roter enhver nøgle, der nogensinde er pushet.
• Kun én branch og ingen beskeder. Fint til solo-eksperimenter, men giv commits klare beskeder, og brug branches til alt risikabelt.
• Redigering to steder på én gang. Hvis du ændrer kode i GitHub og i din AI-appbygger uden at hente ændringer imellem, skaber du konflikter. Vælg ét sted at redigere ad gangen, og synkroniser, før du skifter.
• At tro, at et privat repo er en backup af alt. Det indeholder kode, ikke indholdet af din database eller uploadede filer. Dem skal du sikkerhedskopiere separat.

Hvad du kan bede din AI-appbygger om

• „Tilføj en .gitignore, der udelukker .env, afhængighedsmapper og build-output.“
• „Skriv en README, der forklarer, hvordan man installerer, hvilke miljøvariabler der skal bruges (kun navnene), og hvordan appen køres.“
• „Tilføj en .env.example med alle variabelnavne og uden rigtige værdier.“
• „Brug klare, beskrivende commit-beskeder for hver ændring.“

De fire forespørgsler giver et repository, som en udvikler kan overtage på få minutter. Hvis du vil flytte appen til dine egne servere, se sådan eksporterer og selv-hoster du en AI-bygget app, og for at hærde den inden rigtige brugere, se sådan tager du en AI-prototype til produktion.

GitHub og Mythex

Mythex gemmer historikken for dig på alle planer: efter hver vellykket agent-tur gemmer den et checkpoint, som er et Git-øjebliksbillede, du kan vende tilbage til. På Pro kan du forbinde GitHub og pushe eller pulle projektet mod dit eget repository, eller downloade hele projektet som et arkiv; hemmeligheder og installerede afhængigheder udelukkes fra eksporten. GitHub bruges her til at synkronisere kode, ikke til at logge ind i Mythex. Se GitHub, eksport og import i dokumentationen, og prissiden for, hvad hver plan indeholder.

Spørgsmål