18 KiB

Raw Blame History

Introduktion til GitHub

Denne lektion dækker det grundlæggende i GitHub, en platform til at hoste og administrere ændringer i din kode.

Sketchnote af Tomomi Imura

Quiz før lektionen

Introduktion

I denne lektion vil vi gennemgå:

hvordan du sporer det arbejde, du laver på din maskine
hvordan du arbejder på projekter sammen med andre
hvordan du bidrager til open source-software

Forudsætninger

Før du begynder, skal du tjekke, om Git er installeret. Skriv i terminalen:
git --version

Hvis Git ikke er installeret, download Git. Opsæt derefter din lokale Git-profil i terminalen:

git config --global user.name "dit-navn"
git config --global user.email "din-email"

For at tjekke, om Git allerede er konfigureret, kan du skrive: git config --list

Du skal også bruge en GitHub-konto, en kodeeditor (som Visual Studio Code), og du skal åbne din terminal (eller: kommandoprompt).

Gå til github.com og opret en konto, hvis du ikke allerede har en, eller log ind og udfyld din profil.

✅ GitHub er ikke det eneste koderepositorium i verden; der findes andre, men GitHub er det mest kendte.

Forberedelse

Du skal bruge både en mappe med et kodeprojekt på din lokale maskine (laptop eller PC) og et offentligt repository på GitHub, som vil tjene som et eksempel på, hvordan man bidrager til andres projekter.

Kodehåndtering

Lad os sige, at du har en mappe lokalt med et kodeprojekt, og du vil begynde at spore din fremgang ved hjælp af git - versionskontrolsystemet. Nogle sammenligner brugen af git med at skrive et kærlighedsbrev til dit fremtidige jeg. Når du læser dine commit-beskeder dage, uger eller måneder senere, vil du kunne huske, hvorfor du tog en beslutning, eller "rulle tilbage" en ændring - det vil sige, når du skriver gode "commit-beskeder".

Opgave: Opret et repository og commit kode

Se video

Opret repository på GitHub. På GitHub.com, under repositories-fanen eller fra navigationslinjen øverst til højre, find knappen new repo.
1. Giv dit repository (mappe) et navn.
2. Vælg create repository.
Naviger til din arbejdsmappe. I din terminal skal du skifte til den mappe (også kendt som bibliotek), du vil begynde at spore. Skriv:
```
cd [name of your folder]
```
Initialiser et git repository. I dit projekt skal du skrive:
```
git init
```
Tjek status. For at tjekke status for dit repository skal du skrive:
```
git status
```
Outputtet kan se sådan ud:
```
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

     modified:   file.txt
     modified:   file2.txt
```
Typisk fortæller en git status-kommando dig ting som hvilke filer, der er klar til at blive gemt i repoet, eller som har ændringer, du måske vil gemme.
Tilføj alle filer til sporing
Dette kaldes også at stage filer/tilføje filer til staging-området.
```
git add .
```
Argumentet git add plus . angiver, at alle dine filer og ændringer skal spores.
Tilføj udvalgte filer til sporing
```
git add [file or folder name]
```
Dette hjælper os med kun at tilføje udvalgte filer til staging-området, når vi ikke ønsker at committe alle filer på én gang.
Fjern alle filer fra staging
```
git reset
```
Denne kommando hjælper os med at fjerne alle filer fra staging-området på én gang.
Fjern en bestemt fil fra staging
```
git reset [file or folder name]
```
Denne kommando hjælper os med kun at fjerne en bestemt fil fra staging-området, som vi ikke ønsker at inkludere i den næste commit.
Gem dit arbejde. På dette tidspunkt har du tilføjet filerne til et såkaldt staging-område. Et sted, hvor Git sporer dine filer. For at gøre ændringen permanent skal du commit filerne. For at gøre dette opretter du en commit med kommandoen git commit. En commit repræsenterer et gemmepunkt i historien for dit repo. Skriv følgende for at oprette en commit:
```
git commit -m "first commit"
```
Dette committer alle dine filer og tilføjer beskeden "first commit". For fremtidige commit-beskeder vil du gerne være mere beskrivende for at formidle, hvilken type ændring du har lavet.
Forbind dit lokale Git-repo med GitHub. Et Git-repo er godt på din maskine, men på et tidspunkt vil du gerne have en backup af dine filer et sted og også invitere andre til at arbejde med dig på dit repo. Et godt sted at gøre dette er GitHub. Husk, at vi allerede har oprettet et repo på GitHub, så det eneste, vi skal gøre, er at forbinde vores lokale Git-repo med GitHub. Kommandoen git remote add gør netop dette. Skriv følgende kommando:

Bemærk, før du skriver kommandoen, skal du gå til din GitHub-repo-side for at finde repository-URL'en. Du vil bruge den i nedenstående kommando. Erstat https://github.com/username/repository_name.git med din GitHub-URL.
```
git remote add origin https://github.com/username/repository_name.git
```
Dette opretter en remote, eller forbindelse, kaldet "origin", der peger på det GitHub-repository, du oprettede tidligere.
Send lokale filer til GitHub. Indtil videre har du oprettet en forbindelse mellem det lokale repo og GitHub-repoet. Lad os sende disse filer til GitHub med følgende kommando git push, som følger:

Bemærk, dit branch-navn kan være forskelligt som standard fra main.
```
git push -u origin main
```
Dette sender dine commits i din "main"-branch til GitHub.
Tilføj flere ændringer. Hvis du vil fortsætte med at lave ændringer og sende dem til GitHub, skal du blot bruge følgende tre kommandoer:
```
git add .
git commit -m "type your commit message here"
git push
```
Tip: Du vil måske også adoptere en .gitignore-fil for at forhindre filer, du ikke ønsker at spore, i at dukke op på GitHub - som den notesfil, du gemmer i samme mappe, men som ikke hører hjemme i et offentligt repository. Du kan finde skabeloner til .gitignore-filer på .gitignore templates.

Commit-beskeder

En god Git commit-emnelinje fuldender følgende sætning:
Hvis anvendt, vil denne commit

For emnet skal du bruge den bydeform, nutid: "ændrer" i stedet for "ændrede" eller "ændringer".
Som i emnet skal du også i brødteksten (valgfrit) bruge den bydeform, nutid. Brødteksten bør inkludere motivationen for ændringen og kontrastere dette med tidligere adfærd. Du forklarer hvorfor, ikke hvordan.

✅ Brug et par minutter på at surfe rundt på GitHub. Kan du finde en virkelig god commit-besked? Kan du finde en meget minimal én? Hvilken information synes du er den vigtigste og mest nyttige at formidle i en commit-besked?

Opgave: Samarbejd

Hovedårsagen til at lægge ting på GitHub var at gøre det muligt at samarbejde med andre udviklere.

Arbejde på projekter med andre

Se video

I dit repository skal du navigere til Insights > Community for at se, hvordan dit projekt sammenlignes med anbefalede fællesskabsstandarder.

Her er nogle ting, der kan forbedre dit GitHub-repo:

Beskrivelse. Har du tilføjet en beskrivelse af dit projekt?
README. Har du tilføjet en README? GitHub giver vejledning til at skrive en README.
Retningslinjer for bidrag. Har dit projekt retningslinjer for bidrag?
Adfærdskodeks. Et adfærdskodeks.
Licens. Måske vigtigst af alt, en licens?

Alle disse ressourcer vil gavne onboarding af nye teammedlemmer. Og det er typisk den slags ting, nye bidragydere kigger på, før de overhovedet ser på din kode, for at finde ud af, om dit projekt er det rette sted for dem at bruge deres tid.

✅ README-filer, selvom de tager tid at forberede, bliver ofte forsømt af travle vedligeholdere. Kan du finde et eksempel på en særlig beskrivende én? Bemærk: Der findes nogle værktøjer til at hjælpe med at lave gode READMEs, som du måske vil prøve.

Opgave: Flet noget kode

Bidragsdokumenter hjælper folk med at bidrage til projektet. De forklarer, hvilke typer bidrag du leder efter, og hvordan processen fungerer. Bidragydere skal gennemgå en række trin for at kunne bidrage til dit repo på GitHub:

Fork dit repo. Du vil sandsynligvis have, at folk forker dit projekt. At forke betyder at oprette en kopi af dit repository på deres GitHub-profil.
Klon. Derefter vil de klone projektet til deres lokale maskine.
Opret en branch. Du vil bede dem om at oprette en branch til deres arbejde.
Fokuser deres ændring på ét område. Bed bidragydere om at koncentrere deres bidrag om én ting ad gangen - på den måde er chancerne for, at du kan flette deres arbejde, højere. Forestil dig, at de skriver en fejlrettelse, tilføjer en ny funktion og opdaterer flere tests - hvad nu hvis du kun vil eller kan implementere 2 ud af 3 eller 1 ud af 3 ændringer?

✅ Forestil dig en situation, hvor branches er særligt kritiske for at skrive og levere god kode. Hvilke brugsscenarier kan du komme i tanke om?

Bemærk, vær den forandring, du ønsker at se i verden, og opret branches til dit eget arbejde også. Enhver commit, du laver, vil blive lavet på den branch, du i øjeblikket er "checket ud" til. Brug git status for at se, hvilken branch det er.

Lad os gennemgå en bidragyder-arbejdsgang. Antag, at bidragyderen allerede har forket og klonet repoet, så de har et Git-repo klar til at blive arbejdet på, på deres lokale maskine:

Opret en branch. Brug kommandoen git branch til at oprette en branch, der vil indeholde de ændringer, de ønsker at bidrage med:
```
git branch [branch-name]
```
Skift til arbejdsbranch. Skift til den specificerede branch og opdater arbejdsbiblioteket med git switch:
```
git switch [branch-name]
```
Arbejd. På dette tidspunkt vil du tilføje dine ændringer. Glem ikke at fortælle Git om det med følgende kommandoer:
```
git add .
git commit -m "my changes"
```
Sørg for at give din commit et godt navn, for din egen skyld såvel som for vedligeholderen af det repo, du hjælper med.
Kombiner dit arbejde med main-branchen. På et tidspunkt er du færdig med at arbejde, og du vil kombinere dit arbejde med det i main-branchen. Main-branchen kan have ændret sig i mellemtiden, så sørg for først at opdatere den til den nyeste version med følgende kommandoer:
```
git switch main
git pull
```
På dette tidspunkt vil du sikre dig, at eventuelle konflikter, situationer hvor Git ikke nemt kan kombinere ændringerne, sker i din arbejdsbranch. Derfor skal du køre følgende kommandoer:
```
git switch [branch_name]
git merge main
```
Dette vil bringe alle ændringer fra main ind i din branch, og forhåbentlig kan du bare fortsætte. Hvis ikke, vil VS Code fortælle dig, hvor Git er forvirret, og du ændrer blot de berørte filer for at angive, hvilket indhold der er mest korrekt.
Send dit arbejde til GitHub. At sende dit arbejde til GitHub betyder to ting. At pushe din branch til dit repo og derefter åbne en PR, Pull Request.
```
git push --set-upstream origin [branch-name]
```
Kommandoen ovenfor opretter branchen på dit forkede repo.
Åbn en PR. Dernæst vil du åbne en PR. Det gør du ved at navigere til det forkede repo på GitHub. Du vil se en indikation på GitHub, hvor det spørger, om du vil oprette en ny PR. Klik på det, og du bliver ført til en grænseflade, hvor du kan ændre commit-beskedens titel og give den en mere passende beskrivelse. Nu vil vedligeholderen af det repo, du forkede, se denne PR, og fingrene krydsede, de vil sætte pris på og flette din PR. Du er nu en bidragyder, yay :)
Ryd op. Det anses for god praksis at rydde op, efter du har fået succes med at flette en PR. Du vil rydde op i både din lokale branch og den branch, du pushede til GitHub. Først skal du slette den lokalt med følgende kommando:
```
git branch -d [branch-name]
```
Sørg for at gå til GitHub-siden for det forkede repo og fjerne den remote branch, du lige har pushet til. Pull request virker som et fjollet udtryk, fordi du egentlig ønsker at skubbe dine ændringer til projektet. Men vedligeholderen (projektets ejer) eller kerneholdet skal overveje dine ændringer, før de bliver flettet med projektets "main"-gren, så du anmoder faktisk om en beslutning om ændringen fra en vedligeholder.

En pull request er stedet, hvor man sammenligner og diskuterer forskellene, der er introduceret på en gren, med anmeldelser, kommentarer, integrerede tests og mere. En god pull request følger nogenlunde de samme regler som en commit-besked. Du kan tilføje en reference til et issue i issue tracker, når dit arbejde for eksempel løser et problem. Dette gøres ved at bruge et # efterfulgt af nummeret på dit issue. For eksempel #97.

🤞Kryds fingre for, at alle checks går igennem, og projektets ejer(e) fletter dine ændringer ind i projektet🤞

Opdater din nuværende lokale arbejdsgren med alle nye commits fra den tilsvarende fjern-gren på GitHub:

git pull

Sådan bidrager du til open source

Lad os først finde et repository (eller repo) på GitHub, som interesserer dig, og som du gerne vil bidrage med en ændring til. Du vil gerne kopiere dets indhold til din maskine.

✅ En god måde at finde 'begynder-venlige' repos er at søge efter tagget 'good-first-issue'.

Der er flere måder at kopiere kode på. En måde er at "klone" indholdet af repositoryet ved hjælp af HTTPS, SSH eller GitHub CLI (Command Line Interface).

Åbn din terminal og klon repositoryet sådan her: git clone https://github.com/ProjectURL

For at arbejde på projektet, skift til den rigtige mappe: cd ProjectURL

Du kan også åbne hele projektet ved hjælp af Codespaces, GitHubs indbyggede kodeeditor / cloud-udviklingsmiljø, eller GitHub Desktop.

Til sidst kan du downloade koden i en zippet mappe.

Et par flere interessante ting om GitHub

Du kan stjerne, overvåge og/eller "forke" ethvert offentligt repository på GitHub. Du kan finde dine stjernemarkerede repositories i drop-down-menuen øverst til højre. Det er som bogmærker, men for kode.

Projekter har en issue tracker, som oftest findes på GitHub under fanen "Issues", medmindre andet er angivet, hvor folk diskuterer problemer relateret til projektet. Og fanen Pull Requests er, hvor folk diskuterer og gennemgår ændringer, der er undervejs.

Projekter kan også have diskussioner i fora, mailinglister eller chatkanaler som Slack, Discord eller IRC.

✅ Tag et kig rundt i dit nye GitHub-repo og prøv et par ting, som at redigere indstillinger, tilføje information til dit repo og oprette et projekt (som et Kanban-board). Der er meget, du kan gøre!

🚀 Udfordring

Samarbejd med en ven om hinandens kode. Opret et projekt sammen, fork kode, opret grene og flet ændringer.

Quiz efter forelæsning

Gennemgang & Selvstudie

Læs mere om at bidrage til open source software.

Git cheatsheet.

Øv dig, øv dig, øv dig. GitHub har fantastiske læringsforløb tilgængelige via skills.github.com:

Første uge på GitHub

Du vil også finde mere avancerede kurser.

Opgave

Gennemfør kurset Første uge på GitHub

Ansvarsfraskrivelse:
Dette dokument er blevet oversat ved hjælp af AI-oversættelsestjenesten Co-op Translator. Selvom vi bestræber os på at sikre nøjagtighed, skal du være opmærksom på, at automatiserede oversættelser kan indeholde fejl eller unøjagtigheder. Det originale dokument på dets oprindelige sprog bør betragtes som den autoritative kilde. For kritisk information anbefales professionel menneskelig oversættelse. Vi påtager os intet ansvar for misforståelser eller fejltolkninger, der måtte opstå som følge af brugen af denne oversættelse.

18 KiB Raw Blame History