You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Web-Dev-For-Beginners/translations/no/1-getting-started-lessons/2-github-basics/README.md

38 KiB

Introduksjon til GitHub

Hei der, fremtidige utvikler! 👋 Klar for å bli med millioner av kodere over hele verden? Jeg er virkelig spent på å introdusere deg for GitHub tenk på det som en sosial medieplattform for programmerere, bortsett fra at vi deler kode og bygger fantastiske ting sammen i stedet for å dele bilder av lunsjen vår!

Her er noe som virkelig blåser meg av banen: hver app på telefonen din, hver nettside du besøker, og de fleste verktøyene du kommer til å lære å bruke, ble bygget av team av utviklere som samarbeidet på plattformer akkurat som GitHub. Den musikkappen du elsker? Noen som deg bidro til den. Det spillet du ikke kan legge fra deg? Jepp, sannsynligvis bygget med GitHub-samarbeid. Og nå skal DU lære hvordan du kan bli en del av det fantastiske fellesskapet!

Jeg vet at dette kan føles overveldende i starten jeg husker selv da jeg stirret på min første GitHub-side og tenkte "Hva i all verden betyr dette?" Men her er greia: hver eneste utvikler startet akkurat der du er nå. Innen slutten av denne leksjonen vil du ha din egen GitHub-repository (tenk på det som din personlige prosjektutstilling i skyen), og du vil vite hvordan du lagrer arbeidet ditt, deler det med andre, og til og med bidrar til prosjekter som millioner av mennesker bruker.

Vi skal ta denne reisen sammen, ett steg av gangen. Ingen hastverk, ingen press bare deg, meg, og noen virkelig kule verktøy som snart kommer til å bli dine nye bestevenner!

Intro til GitHub

Sketchnote av Tomomi Imura

Quiz før leksjonen

Quiz før leksjonen

Introduksjon

Før vi dykker inn i de virkelig spennende tingene, la oss gjøre datamaskinen din klar for litt GitHub-magi! Tenk på dette som å organisere kunstforsyningene dine før du lager et mesterverk å ha de riktige verktøyene klare gjør alt så mye enklere og mye morsommere.

Jeg skal gå gjennom hvert oppsettsteg med deg personlig, og jeg lover at det ikke er i nærheten av så skremmende som det kanskje ser ut ved første øyekast. Hvis noe ikke gir mening med en gang, er det helt normalt! Jeg husker da jeg satte opp mitt første utviklingsmiljø og følte meg som om jeg prøvde å lese gamle hieroglyfer. Hver eneste utvikler har vært akkurat der du er nå, og lurt på om de gjør det riktig. Spoiler: hvis du er her og lærer, gjør du det allerede riktig! 🌟

I denne leksjonen skal vi dekke:

  • hvordan du sporer arbeidet du gjør på maskinen din
  • hvordan du jobber med prosjekter sammen med andre
  • hvordan du kan bidra til åpen kildekode-programvare

Forutsetninger

La oss gjøre datamaskinen din klar for litt GitHub-magi! Ikke bekymre deg dette oppsettet er noe du bare trenger å gjøre én gang, og deretter er du klar for hele kodereisen din.

Ok, la oss starte med grunnlaget! Først må vi sjekke om Git allerede er installert på datamaskinen din. Git er i utgangspunktet som å ha en super-smart assistent som husker hver eneste endring du gjør i koden din mye bedre enn å frenetisk trykke Ctrl+S hvert andre sekund (vi har alle vært der!).

La oss se om Git allerede er installert ved å skrive denne magiske kommandoen i terminalen din: git --version

Hvis Git ikke er der ennå, ingen grunn til bekymring! Bare gå til last ned Git og last det ned. Når du har installert det, må vi introdusere Git ordentlig for deg:

💡 Første gangs oppsett: Disse kommandoene forteller Git hvem du er. Denne informasjonen vil bli knyttet til hver commit du gjør, så velg et navn og en e-postadresse du er komfortabel med å dele offentlig.

git config --global user.name "your-name"
git config --global user.email "your-email"

For å sjekke om Git allerede er konfigurert, kan du skrive:

git config --list

Du trenger også en GitHub-konto, en kodeeditor (som Visual Studio Code), og du må åpne terminalen din (eller: kommandolinjen).

Gå til github.com og opprett en konto hvis du ikke allerede har en, eller logg inn og fyll ut profilen din.

💡 Moderne tips: Vurder å sette opp SSH-nøkler eller bruke GitHub CLI for enklere autentisering uten passord.

GitHub er ikke det eneste kode-repositoriet i verden; det finnes andre, men GitHub er det mest kjente.

Forberedelse

Du trenger både en mappe med et kodeprosjekt på din lokale maskin (laptop eller PC), og et offentlig repository på GitHub, som vil fungere som et eksempel på hvordan du kan bidra til andres prosjekter.

Hold koden din trygg

La oss snakke om sikkerhet et øyeblikk men ikke bekymre deg, vi skal ikke overvelde deg med skumle ting! Tenk på disse sikkerhetspraksisene som å låse bilen eller huset ditt. De er enkle vaner som blir en selvfølge og holder det harde arbeidet ditt beskyttet.

Vi skal vise deg moderne, sikre måter å jobbe med GitHub fra starten av. På denne måten vil du utvikle gode vaner som vil tjene deg godt gjennom hele kodingskarrieren din.

Når du jobber med GitHub, er det viktig å følge sikkerhetspraksis:

Sikkerhetsområde Beste praksis Hvorfor det er viktig
Autentisering Bruk SSH-nøkler eller Personlige Tilgangstokens Passord er mindre sikre og blir faset ut
Tofaktorautentisering Aktiver 2FA på GitHub-kontoen din Gir et ekstra lag med kontobeskyttelse
Repository-sikkerhet Aldri commit sensitiv informasjon API-nøkler og passord skal aldri være i offentlige repositorier
Avhengighetsstyring Aktiver Dependabot for oppdateringer Holder avhengighetene dine sikre og oppdaterte

⚠️ Kritisk sikkerhetspåminnelse: Aldri commit API-nøkler, passord eller annen sensitiv informasjon til noe repository. Bruk miljøvariabler og .gitignore-filer for å beskytte sensitiv data.

Moderne autentiseringsoppsett:

# Generate SSH key (modern ed25519 algorithm)
ssh-keygen -t ed25519 -C "your_email@example.com"

# Set up Git to use SSH
git remote set-url origin git@github.com:username/repository.git

💡 Proff-tips: SSH-nøkler eliminerer behovet for å skrive inn passord gjentatte ganger og er mer sikre enn tradisjonelle autentiseringsmetoder.


Administrer koden din som en proff

Ok, NÅ blir det virkelig spennende! 🎉 Vi skal lære hvordan du sporer og administrerer koden din som proffene gjør, og helt ærlig, dette er en av mine favoritting å lære bort fordi det er en skikkelig game-changer.

Se for deg dette: du skriver en fantastisk historie, og du vil holde styr på hver utkast, hver briljant redigering, og hver "vent, det der er genialt!"-øyeblikk underveis. Det er akkurat det Git gjør for koden din! Det er som å ha den mest utrolige tidsreisende notatboken som husker ALT hver tastetrykk, hver endring, hver "oi, det ødela alt"-øyeblikk som du umiddelbart kan angre.

Jeg skal være ærlig dette kan føles overveldende i starten. Da jeg begynte, tenkte jeg "Hvorfor kan jeg ikke bare lagre filene mine som vanlig?" Men stol på meg: når Git klikker for deg (og det vil!), vil du ha et av de lyspære-øyeblikkene hvor du tenker "Hvordan har jeg NOEN GANG kodet uten dette?" Det er som å oppdage at du kan fly når du har gått overalt hele livet!

La oss si at du har en mappe lokalt med et kodeprosjekt, og du vil begynne å spore fremgangen din ved hjelp av git versjonskontrollsystemet. Noen sammenligner det å bruke git med å skrive et kjærlighetsbrev til ditt fremtidige jeg. Når du leser commit-meldingene dine dager, uker eller måneder senere, vil du kunne huske hvorfor du tok en beslutning, eller "rulle tilbake" en endring det vil si, når du skriver gode "commit-meldinger".

Oppgave: Opprett ditt første repository!

🎯 Din oppgave (og jeg er så spent på deg!): Vi skal opprette ditt aller første GitHub-repository sammen! Når vi er ferdige her, vil du ha din egen lille hjørne av internett hvor koden din bor, og du vil ha gjort din første "commit" (det er utviklerspråk for å lagre arbeidet ditt på en veldig smart måte).

Dette er ærlig talt et så spesielt øyeblikk du er i ferd med å offisielt bli med i det globale fellesskapet av utviklere! Jeg husker fortsatt spenningen ved å opprette mitt første repo og tenke "Wow, jeg gjør virkelig dette!"

La oss gå gjennom dette eventyret sammen, steg for steg. Ta deg god tid med hver del det er ingen premie for å skynde seg, og jeg lover at hvert eneste steg vil gi mening. Husk, hver kodestjerne du beundrer, satt en gang akkurat der du er nå, klar til å opprette sitt første repository. Hvor kult er det?

Sjekk ut videoen

Git og GitHub grunnleggende video

La oss gjøre dette sammen:

  1. Opprett ditt repository på GitHub. Gå til GitHub.com og se etter den lysegrønne Ny-knappen (eller +-tegnet øverst til høyre). Klikk på den og velg Nytt repository.

    Slik gjør du det:

    1. Gi repositoryet ditt et navn velg noe som betyr noe for deg!
    2. Legg til en beskrivelse hvis du vil (dette hjelper andre med å forstå hva prosjektet ditt handler om)
    3. Bestem om du vil ha det offentlig (alle kan se det) eller privat (bare for deg)
    4. Jeg anbefaler å krysse av for å legge til en README-fil det er som forsiden av prosjektet ditt
    5. Klikk Opprett repository og feir du har nettopp opprettet ditt første repo! 🎉
  2. Naviger til prosjektmappen din. Nå skal vi åpne terminalen din (ikke bekymre deg, det er ikke så skummelt som det ser ut!). Vi må fortelle datamaskinen hvor prosjektfilene dine er. Skriv denne kommandoen:

    cd [name of your folder]
    

    Hva vi gjør her:

    • Vi sier i utgangspunktet "Hei datamaskin, ta meg til prosjektmappen min"
    • Dette er som å åpne en spesifikk mappe på skrivebordet ditt, men vi gjør det med tekstkommandoer
    • Erstatt [navnet på mappen din] med det faktiske navnet på prosjektmappen din
  3. Gjør mappen din om til et Git repository. Her skjer magien! Skriv:

    git init
    

    Her er hva som nettopp skjedde (ganske kult!):

    • Git opprettet en skjult .git-mappe i prosjektet ditt du ser den ikke, men den er der!
    • Den vanlige mappen din er nå et "repository" som kan spore hver endring du gjør
    • Tenk på det som å gi mappen din superkrefter til å huske alt
  4. Sjekk hva som skjer. La oss se hva Git tenker om prosjektet ditt akkurat nå:

    git status
    

    Forstå hva Git forteller deg:

    Du kan se noe som ser slik ut:

    Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git restore <file>..." to discard changes in working directory)
    
         modified:   file.txt
         modified:   file2.txt
    

    Ikke få panikk! Her er hva dette betyr:

    • Filer i rødt er filer som har endringer, men som ikke er klare til å lagres ennå
    • Filer i grønt (når du ser dem) er klare til å lagres
    • Git er hjelpsom ved å fortelle deg nøyaktig hva du kan gjøre videre

    💡 Proff-tips: Kommandoen git status er din beste venn! Bruk den når som helst du er forvirret over hva som skjer. Det er som å spørre Git "Hei, hva er situasjonen akkurat nå?"

  5. Gjør filene dine klare til å lagres (dette kalles "staging"):

    git add .
    

    Hva vi nettopp gjorde:

    • Vi fortalte Git "Hei, jeg vil inkludere ALLE filene mine i neste lagring"
    • . er som å si "alt i denne mappen"
    • Nå er filene dine "staged" og klare for neste steg

    Vil du være mer selektiv? Du kan legge til bare spesifikke filer:

    git add [file or folder name]
    

    Hvorfor vil du kanskje gjøre dette?

    • Noen ganger vil du lagre relaterte endringer sammen
    • Det hjelper deg med å organisere arbeidet ditt i logiske deler
    • Gjør det lettere å forstå hva som endret seg og når

    Endret mening? Ingen problem! Du kan fjerne filer fra staging slik:

    # Unstage everything
    git reset
    
    # Unstage just one file
    git reset [file name]
    

    Ikke bekymre deg dette sletter ikke arbeidet ditt, det tar bare filene ut av "klar til å lagres"-bunken.

  6. Lagre arbeidet ditt permanent (gjør din første commit!):

    git commit -m "first commit"
    

    🎉 Gratulerer! Du har nettopp gjort din første commit!

    Her er hva som nettopp skjedde:

    • Git tok et "snapshot" av alle de staged filene dine akkurat nå
    • Commit-meldingen "første commit" forklarer hva dette lagringspunktet handler om
    • Git ga dette snapshotet en unik ID slik at du alltid kan finne det senere
    • Du har offisielt begynt å spore prosjektets historie!

    💡 Fremtidige commit-meldinger: For dine neste commits, vær mer beskrivende! I stedet for "oppdatert ting", prøv "La til kontaktskjema på hjemmesiden" eller "Fikset feil i navigasjonsmenyen". Ditt fremtidige jeg vil takke deg!

  7. Koble ditt lokale prosjekt til GitHub. Akkurat nå eksisterer prosjektet ditt bare på datamaskinen din. La oss koble det til GitHub-repositoryet ditt slik at du kan dele det med verden!

    Først, gå til GitHub-repository-siden din og kopier URL-en. Deretter kommer du tilbake hit og skriver:

    git remote add origin https://github.com/username/repository_name.git
    

    (Erstatt den URL-en med din faktiske repository-URL!)

    Hva vi nettopp gjorde:

  • Vi har opprettet en forbindelse mellom ditt lokale prosjekt og GitHub-repositoriet ditt
  • "Origin" er bare et kallenavn for GitHub-repositoriet ditt det er som å legge til en kontakt på telefonen din
  • Nå vet ditt lokale Git hvor det skal sende koden din når du er klar til å dele den

💡 Enklere måte: Hvis du har GitHub CLI installert, kan du gjøre dette med én kommando:

gh repo create my-repo --public --push --source=.
  1. Send koden din til GitHub (det store øyeblikket!):

    git push -u origin main
    

🚀 Dette er det! Du laster opp koden din til GitHub!

Hva som skjer:

  • Dine commits reiser fra datamaskinen din til GitHub
  • -u-flagget setter opp en permanent forbindelse slik at fremtidige pushes blir enklere
  • "main" er navnet på din primære branch (som hovedmappen)
  • Etter dette kan du bare skrive git push for fremtidige opplastinger!

💡 Raskt notat: Hvis branchen din heter noe annet (som "master"), bruk det navnet i stedet. Du kan sjekke med git branch --show-current.

  1. Din nye daglige koderytme (her blir det vanedannende!):

Fra nå av, hver gang du gjør endringer i prosjektet ditt, har du denne enkle tretrinnsprosessen:

git add .
git commit -m "describe what you changed"
git push

Dette blir din kodingspuls:

  • Gjør noen fantastiske endringer i koden din
  • Stage dem med git add ("Hei Git, følg med på disse endringene!")
  • Lagre dem med git commit og en beskrivende melding (fremtidige deg vil takke deg!)
  • Del dem med verden ved å bruke git push 🚀
  • Gjenta seriøst, dette blir like naturlig som å puste!

Jeg elsker denne arbeidsflyten fordi det er som å ha flere lagringspunkter i et videospill. Gjorde du en endring du elsker? Commit den! Vil du prøve noe risikabelt? Ikke noe problem du kan alltid gå tilbake til din siste commit hvis ting går galt!

💡 Tips: Du vil kanskje også ta i bruk en .gitignore-fil for å forhindre at filer du ikke vil spore dukker opp på GitHub som den notatfilen du lagrer i samme mappe, men som ikke har noe å gjøre i et offentlig repository. Du kan finne maler for .gitignore-filer på .gitignore templates eller lage en ved hjelp av gitignore.io.

Moderne Git-arbeidsflyter

Vurder å ta i bruk disse moderne praksisene:

  • Conventional Commits: Bruk et standardisert format for commit-meldinger som feat:, fix:, docs: osv. Lær mer på conventionalcommits.org
  • Atomiske commits: Sørg for at hver commit representerer én logisk endring
  • Hyppige commits: Commit ofte med beskrivende meldinger i stedet for store, sjeldne commits

Commit-meldinger

En god Git-commit-emnelinje fullfører følgende setning:
Hvis den brukes, vil denne commiten

For emnet, bruk imperativ, nåtid: "endre" ikke "endret" eller "endrer".
Som i emnet, bruk også imperativ, nåtid i kroppen (valgfritt). Kroppen bør inkludere motivasjonen for endringen og kontrastere dette med tidligere oppførsel. Du forklarer hvorfor, ikke hvordan.

Ta noen minutter til å surfe rundt på GitHub. Kan du finne en virkelig god commit-melding? Kan du finne en veldig minimal en? Hvilken informasjon synes du er den viktigste og mest nyttige å formidle i en commit-melding?

Samarbeid med andre (Den morsomme delen!)

Hold på hatten, for NÅ blir GitHub helt magisk! 🪄 Du har mestret å administrere din egen kode, men nå dykker vi inn i min absolutte favorittdel å samarbeide med fantastiske mennesker fra hele verden.

Se for deg dette: Du våkner i morgen og ser at noen i Tokyo har forbedret koden din mens du sov. Så fikser noen i Berlin en feil du har slitt med. Innen ettermiddagen har en utvikler i São Paulo lagt til en funksjon du aldri engang hadde tenkt på. Det er ikke science fiction det er bare en vanlig tirsdag i GitHub-universet!

Det som virkelig begeistrer meg er at samarbeidsferdighetene du er i ferd med å lære? Dette er de EKSAKTE samme arbeidsflytene som teamene hos Google, Microsoft og dine favorittstartups bruker hver eneste dag. Du lærer ikke bare et kult verktøy du lærer det hemmelige språket som får hele programvareverdenen til å samarbeide.

Seriøst, når du opplever gleden av at noen godkjenner din første pull request, vil du forstå hvorfor utviklere blir så lidenskapelige om åpen kildekode. Det er som å være en del av verdens største, mest kreative teamprosjekt!

Se video

Git og GitHub grunnleggende video

Hovedgrunnen til å legge ting på GitHub var å gjøre det mulig å samarbeide med andre utviklere.

I ditt repository, naviger til Insights > Community for å se hvordan prosjektet ditt sammenlignes med anbefalte fellesskapsstandarder.

Vil du få repositoryet ditt til å se profesjonelt og innbydende ut? Gå til repositoryet ditt og klikk på Insights > Community. Denne kule funksjonen viser deg hvordan prosjektet ditt sammenlignes med det GitHub-fellesskapet anser som "gode repository-praksiser."

🎯 Få prosjektet ditt til å skinne: Et godt organisert repository med god dokumentasjon er som å ha en ren, innbydende butikkfront. Det viser folk at du bryr deg om arbeidet ditt og får andre til å ville bidra!

Dette gjør et repository fantastisk:

Hva du bør legge til Hvorfor det er viktig Hva det gjør for deg
Beskrivelse Førsteinntrykk teller! Folk vet umiddelbart hva prosjektet ditt gjør
README Forsiden til prosjektet ditt Som en vennlig guide for nye besøkende
Retningslinjer for bidrag Viser at du ønsker hjelp Folk vet nøyaktig hvordan de kan hjelpe deg
Adferdskodeks Skaper et vennlig miljø Alle føler seg velkomne til å delta
Lisens Juridisk klarhet Andre vet hvordan de kan bruke koden din
Sikkerhetspolicy Viser at du er ansvarlig Demonstrerer profesjonelle praksiser

💡 Profftips: GitHub tilbyr maler for alle disse filene. Når du oppretter et nytt repository, huk av boksene for å automatisk generere disse filene.

Moderne GitHub-funksjoner å utforske:

🤖 Automatisering & CI/CD:

  • GitHub Actions for automatisert testing og distribusjon
  • Dependabot for automatiske oppdateringer av avhengigheter

💬 Fellesskap & Prosjektledelse:

  • GitHub Discussions for fellesskapsdiskusjoner utover issues
  • GitHub Projects for kanban-stil prosjektledelse
  • Branch-beskyttelsesregler for å opprettholde kodekvalitetsstandarder

Alle disse ressursene vil være nyttige for å onboarde nye teammedlemmer. Og dette er typisk ting nye bidragsytere ser på før de i det hele tatt ser på koden din, for å finne ut om prosjektet ditt er det rette stedet for dem å bruke tiden sin.

README-filer, selv om de tar tid å forberede, blir ofte oversett av travle vedlikeholdere. Kan du finne et eksempel på en spesielt beskrivende README? Merk: det finnes noen verktøy for å lage gode README-filer som du kanskje vil prøve.

Oppgave: Merge litt kode

Bidragsdokumenter hjelper folk med å bidra til prosjektet. Det forklarer hvilke typer bidrag du ser etter og hvordan prosessen fungerer. Bidragsytere må gå gjennom en serie med steg for å kunne bidra til ditt repo på GitHub:

  1. Forke repoet ditt Du vil sannsynligvis at folk skal forke prosjektet ditt. Forking betyr å lage en kopi av repositoryet ditt på deres GitHub-profil.
  2. Clone. Derfra vil de klone prosjektet til sin lokale maskin.
  3. Opprette en branch. Du vil be dem om å opprette en branch for arbeidet sitt.
  4. Fokusere endringen på ett område. Be bidragsytere om å konsentrere bidragene sine på én ting av gangen på den måten øker sjansen for at du kan merge arbeidet deres. Tenk deg at de skriver en feilretting, legger til en ny funksjon og oppdaterer flere tester hva om du vil, eller bare kan implementere 2 av 3, eller 1 av 3 endringer?

Tenk deg en situasjon der branches er spesielt kritiske for å skrive og levere god kode. Hvilke bruksområder kan du komme på?

Merk, vær den endringen du ønsker å se i verden, og opprett branches for ditt eget arbeid også. Alle commits du gjør vil bli gjort på branchen du for øyeblikket er "checked out" til. Bruk git status for å se hvilken branch det er.

La oss gå gjennom en bidragsarbeidsflyt. Anta at bidragsyteren allerede har forket og klonet repoet, så de har et Git-repo klart til å jobbe med på sin lokale maskin:

  1. Opprett en branch. Bruk kommandoen git branch for å opprette en branch som vil inneholde endringene de har tenkt å bidra med:

    git branch [branch-name]
    

    💡 Moderne tilnærming: Du kan også opprette og bytte til den nye branchen med én kommando:

    git switch -c [branch-name]
    
  2. Bytt til arbeidsbranch. Bytt til den spesifiserte branchen og oppdater arbeidskatalogen med git switch:

    git switch [branch-name]
    

    💡 Moderne notat: git switch er den moderne erstatningen for git checkout når du bytter branch. Det er tydeligere og tryggere for nybegynnere.

  3. Utfør arbeid. På dette tidspunktet kan du legge til endringene dine. Ikke glem å informere Git om det med følgende kommandoer:

    git add .
    git commit -m "my changes"
    

    ⚠️ Kvalitet på commit-meldinger: Sørg for å gi commiten din et godt navn, både for din egen del og for vedlikeholderen av repoet du hjelper til med. Vær spesifikk om hva du har endret!

  4. Kombiner arbeidet ditt med main-branchen. På et tidspunkt er du ferdig med arbeidet og ønsker å kombinere det med main-branchen. main-branchen kan ha endret seg i mellomtiden, så sørg for å oppdatere den til det nyeste med følgende kommandoer:

    git switch main
    git pull
    

    På dette tidspunktet vil du sørge for at eventuelle konflikter, situasjoner der Git ikke enkelt kan kombinere endringene, skjer i din arbeidsbranch. Derfor kjør følgende kommandoer:

    git switch [branch_name]
    git merge main
    

    Kommandoen git merge main vil hente inn alle endringer fra main til din branch. Forhåpentligvis kan du bare fortsette. Hvis ikke, vil VS Code fortelle deg hvor Git er forvirret, og du kan endre de berørte filene for å angi hvilket innhold som er mest nøyaktig.

    💡 Moderne alternativ: Vurder å bruke git rebase for en renere historikk:

    git rebase main
    

    Dette spiller av dine commits på toppen av den nyeste main-branchen, og skaper en lineær historikk.

  5. Send arbeidet ditt til GitHub. Å sende arbeidet ditt til GitHub betyr to ting. Å pushe branchen din til repoet ditt og deretter åpne en PR, Pull Request.

    git push --set-upstream origin [branch-name]
    

    Kommandoen ovenfor oppretter branchen på ditt forkede repo.

  6. Åpne en PR. Deretter vil du åpne en PR. Du gjør det ved å navigere til det forkede repoet på GitHub. Du vil se en indikasjon på GitHub hvor det spør om du vil opprette en ny PR, du klikker på det og blir tatt til et grensesnitt hvor du kan endre commit-meldingens tittel, gi den en mer passende beskrivelse. Nå vil vedlikeholderen av repoet du forked se denne PR-en og krysser fingrene for at de setter pris på og merger PR-en din. Du er nå en bidragsyter, yay :)

    💡 Moderne tips: Du kan også opprette PR-er ved hjelp av GitHub CLI:

    gh pr create --title "Your PR title" --body "Description of changes"
    

    🔧 Beste praksis for PR-er:

    • Link til relaterte issues ved å bruke nøkkelord som "Fixes #123"
    • Legg til skjermbilder for UI-endringer
    • Be om spesifikke anmeldere
    • Bruk utkast-PR-er for arbeid som pågår
    • Sørg for at alle CI-sjekker er bestått før du ber om gjennomgang
  7. Rydd opp. Det anses som god praksis å rydde opp etter at du har lykkes med å merge en PR. Du vil rydde opp både din lokale branch og branchen du pushet til GitHub. Først, la oss slette den lokalt med følgende kommando:

    git branch -d [branch-name]
    

    Sørg for å gå til GitHub-siden for det forkede repoet og fjern den eksterne branchen du nettopp pushet til.

Pull request virker som et rart begrep fordi du egentlig ønsker å pushe endringene dine til prosjektet. Men vedlikeholderen (prosjekteieren) eller kjerneteamet må vurdere endringene dine før de merger dem med prosjektets "main"-branch, så du ber egentlig om en beslutning om endringen fra en vedlikeholder.

En pull request er stedet for å sammenligne og diskutere forskjellene som er introdusert på en branch med anmeldelser, kommentarer, integrerte tester og mer. En god pull request følger omtrent de samme reglene som en commit-melding. Du kan legge til en referanse til en issue i issue-tracker, når arbeidet ditt for eksempel fikser en issue. Dette gjøres ved å bruke en # etterfulgt av nummeret på din issue. For eksempel #97.
🤞Krysser fingrene for at alle sjekker går gjennom og at prosjektets eier(e) godkjenner endringene dine og slår dem sammen med prosjektet🤞

Oppdater din nåværende lokale arbeidsgren med alle nye commits fra den tilsvarende eksterne grenen på GitHub:

git pull

Bidra til Open Source (Din sjanse til å gjøre en forskjell!)

Er du klar for noe som kommer til å blåse deg helt av banen? 🤯 La oss snakke om å bidra til open source-prosjekter jeg får gåsehud bare av å dele dette med deg!

Dette er din sjanse til å bli en del av noe virkelig ekstraordinært. Tenk deg å forbedre verktøyene som millioner av utviklere bruker hver dag, eller fikse en feil i en app som vennene dine elsker. Det er ikke bare en drøm det er det open source-bidrag handler om!

Her er det som gir meg frysninger hver gang jeg tenker på det: hvert eneste verktøy du har lært med kodeeditoren din, rammeverkene vi skal utforske, til og med nettleseren du leser dette i startet med noen akkurat som deg som gjorde sitt aller første bidrag. Den geniale utvikleren som bygde din favoritt-VS Code-utvidelse? De var en gang en nybegynner som klikket "create pull request" med skjelvende hender, akkurat som du er i ferd med å gjøre.

Og her er det vakreste: open source-samfunnet er som internettets største gruppesamling. De fleste prosjekter ser aktivt etter nykommere og har problemer merket "good first issue" spesielt for folk som deg! Vedlikeholdere blir genuint begeistret når de ser nye bidragsytere fordi de husker sine egne første steg.

Du lærer ikke bare å kode her du forbereder deg på å bli med i en global familie av skapere som våkner hver dag og tenker "Hvordan kan vi gjøre den digitale verden litt bedre?" Velkommen til klubben! 🌟

Først, la oss finne et repository (eller repo) på GitHub som interesserer deg og som du ønsker å bidra med en endring til. Du vil kopiere innholdet til din maskin.

En god måte å finne 'nybegynnervennlige' repoer på er å søke etter taggen 'good-first-issue'.

Kopier et repo lokalt

Det finnes flere måter å kopiere kode på. En måte er å "klone" innholdet i repositoryet, ved å bruke HTTPS, SSH eller GitHub CLI (Command Line Interface).

Åpne terminalen din og klon repositoryet slik:

# Using HTTPS
git clone https://github.com/ProjectURL

# Using SSH (requires SSH key setup)
git clone git@github.com:username/repository.git

# Using GitHub CLI
gh repo clone username/repository

For å jobbe med prosjektet, bytt til riktig mappe: cd ProjectURL

Du kan også åpne hele prosjektet ved å bruke:

  • GitHub Codespaces - GitHubs skyutviklingsmiljø med VS Code i nettleseren
  • GitHub Desktop - En GUI-applikasjon for Git-operasjoner
  • GitHub.dev - Trykk på .-tasten på et hvilket som helst GitHub-repo for å åpne VS Code i nettleseren
  • VS Code med GitHub Pull Requests-utvidelsen

Til slutt kan du laste ned koden i en zip-mappe.

Noen flere interessante ting om GitHub

Du kan stjerne, følge og/eller "forke" ethvert offentlig repository på GitHub. Du finner dine stjernemerkede repositories i rullegardinmenyen øverst til høyre. Det er som bokmerker, men for kode.

Prosjekter har en problemsporer, som oftest på GitHub under "Issues"-fanen med mindre annet er angitt, hvor folk diskuterer problemer relatert til prosjektet. Og Pull Requests-fanen er der folk diskuterer og vurderer endringer som er under behandling.

Prosjekter kan også ha diskusjoner i forum, e-postlister eller chattekanaler som Slack, Discord eller IRC.

🔧 Moderne GitHub-funksjoner:

  • GitHub Discussions - Innebygd forum for samtaler i fellesskapet
  • GitHub Sponsors - Støtt vedlikeholdere økonomisk
  • Security-fanen - Rapporter om sårbarheter og sikkerhetsråd
  • Actions-fanen - Se automatiserte arbeidsflyter og CI/CD-pipelines
  • Insights-fanen - Analyse om bidragsytere, commits og prosjektets helse
  • Projects-fanen - GitHubs innebygde prosjektstyringsverktøy

Ta en titt rundt i ditt nye GitHub-repo og prøv noen ting, som å redigere innstillinger, legge til informasjon i repoet ditt, opprette et prosjekt (som et Kanban-brett), og sette opp GitHub Actions for automatisering. Det er mye du kan gjøre!


🚀 Utfordring

Ok, det er på tide å teste dine nye GitHub-superkrefter! 🚀 Her er en utfordring som kommer til å få alt til å falle på plass på den mest tilfredsstillende måten:

Ta med deg en venn (eller et familiemedlem som alltid spør hva du driver med når du sitter foran datamaskinen) og begi dere ut på et samarbeidsprosjekt sammen! Her skjer den virkelige magien opprett et prosjekt, la dem forke det, lag noen grener og slå sammen endringer som de proffene dere er i ferd med å bli.

Jeg skal ikke lyve dere kommer sannsynligvis til å le på et tidspunkt (spesielt når dere begge prøver å endre den samme linjen), kanskje klø dere i hodet av forvirring, men dere vil definitivt ha de fantastiske "aha!"-øyeblikkene som gjør all læringen verdt det. I tillegg er det noe spesielt med å dele den første vellykkede sammenslåingen med noen andre det er som en liten feiring av hvor langt dere har kommet!

Har du ikke en kodevenn ennå? Ingen problem! GitHub-samfunnet er fullt av utrolig velkomne mennesker som husker hvordan det var å være ny. Se etter repositories med "good first issue"-etiketter de sier i bunn og grunn "Hei nybegynnere, kom og lær med oss!" Hvor kult er ikke det?

Quiz etter forelesning

Quiz etter forelesning

Oppsummering & Fortsett å lære

Puh! 🎉 Se på deg du har nettopp mestret GitHub-grunnleggende som en ekte mester! Hvis hjernen din føles litt full akkurat nå, er det helt normalt og faktisk et godt tegn. Du har nettopp lært verktøy som tok meg uker å bli komfortabel med da jeg startet.

Git og GitHub er utrolig kraftige (som, seriøst kraftige), og hver utvikler jeg kjenner inkludert de som nå virker som trollmenn måtte øve og snuble litt før alt falt på plass. Det faktum at du har kommet deg gjennom denne leksjonen betyr at du allerede er på vei til å mestre noen av de viktigste verktøyene i en utviklers verktøykasse.

Her er noen helt fantastiske ressurser for å hjelpe deg med å øve og bli enda mer fantastisk:

Og husk: øvelse gir fremgang, ikke perfeksjon! Jo mer du bruker Git og GitHub, jo mer naturlig blir det. GitHub har laget noen fantastiske interaktive kurs som lar deg øve i et trygt miljø:

Føler du deg eventyrlysten? Sjekk ut disse moderne verktøyene:

GitHub Copilot Agent Challenge 🚀

Bruk Agent-modus for å fullføre følgende utfordring:

Beskrivelse: Opprett et samarbeidsprosjekt for webutvikling som demonstrerer hele GitHub-arbeidsflyten du har lært i denne leksjonen. Denne utfordringen vil hjelpe deg med å øve på opprettelse av repository, samarbeidsfunksjoner og moderne Git-arbeidsflyter i et realistisk scenario.

Oppgave: Opprett et nytt offentlig GitHub-repository for et enkelt "Web Development Resources"-prosjekt. Repositoryet bør inkludere en godt strukturert README.md-fil som lister opp nyttige verktøy og ressurser for webutvikling, organisert etter kategorier (HTML, CSS, JavaScript, osv.). Sett opp repositoryet med riktige fellesskapsstandarder, inkludert lisens, retningslinjer for bidrag og en adferdskodeks. Opprett minst to funksjonsgrener: en for å legge til CSS-ressurser og en annen for JavaScript-ressurser. Gjør commits til hver gren med beskrivende commit-meldinger, og opprett deretter pull requests for å slå sammen endringene tilbake til main. Aktiver GitHub-funksjoner som Issues, Discussions, og sett opp en grunnleggende GitHub Actions-arbeidsflyt for automatiserte sjekker.

Oppgave

Din oppgave, hvis du velger å akseptere den: Fullfør Introduksjon til GitHub-kurset på GitHub Skills. Dette interaktive kurset lar deg øve på alt du har lært i et trygt, veiledet miljø. I tillegg får du et kult merke når du er ferdig! 🏅

Føler du deg klar for flere utfordringer?

  • Sett opp SSH-autentisering for GitHub-kontoen din (slutt på passord!)
  • Prøv å bruke GitHub CLI for dine daglige Git-operasjoner
  • Opprett et repository med en GitHub Actions-arbeidsflyt
  • Utforsk GitHub Codespaces ved å åpne akkurat dette repositoryet i en skybasert editor

Husk: hver ekspert var en gang nybegynner. Du klarer dette! 💪


Ansvarsfraskrivelse:
Dette dokumentet er oversatt ved hjelp av AI-oversettelsestjenesten Co-op Translator. Selv om vi streber etter nøyaktighet, vær oppmerksom på at automatiske oversettelser kan inneholde feil eller unøyaktigheter. Det originale dokumentet på sitt opprinnelige språk bør anses som den autoritative kilden. For kritisk informasjon anbefales profesjonell menneskelig oversettelse. Vi er ikke ansvarlige for eventuelle misforståelser eller feiltolkninger som oppstår ved bruk av denne oversettelsen.