Topp 25 Git-intervjufrågor och svar för alla nivåer

Grundläggande Git-intervjufrågor

Om du är relativt ny på Git kommer vissa grundläggande intervjufrågor sannolikt att beröra nybörjarkoncept och användningsfall. Om du behöver fräscha upp kunskaperna, titta gärna på DataCamps kurs Introduction to Git.

Vad är ett Git-repository?

Ett Git-repository lagrar ett projekts filer och versionshistorik och underlättar versionshantering genom att spåra förändringar över tid. Det kan finnas lokalt i en mapp på din enhet eller på en onlineplattform som GitHub. Detta gör det möjligt för användare att samarbeta, återgå till tidigare versioner och effektivt hantera projektutvecklingen med kommandon som commit, push och pull.

Hur fungerar Git?

Git fungerar genom att registrera ändringar som görs i filer och kataloger i ett projekt och fångar ögonblicksbilder av dess föränderliga tillstånd. Användare kan överblicka ändringar, skapa grenar för parallell utveckling, slå samman grenar och återgå till tidigare lägen vid behov. Det främjar samarbete och säkerställer effektiv versionshantering i mjukvaruutveckling.

Vad är git add?

Kommandot git add används i Git för att lägga ändringar i staging inför nästa commit. Det förbereder modifieringar, tillägg eller borttagningar som gjorts i arbetskatalogen och markerar dem för att ingå i nästa commit-ögonblicksbild. Observera att detta kommando inte faktiskt committar ändringarna utan förbereder dem för staging.

Vad är git push?

Kommandot git push används i Git för att ladda upp innehåll från det lokala repositoriet till ett fjärrepositorium. Det överför committade ändringar från det lokala repositoriet till ett fjärrrepo, vanligtvis på en server som GitHub eller GitLab. Detta kommando möjliggör samarbete genom att låta användare dela sina ändringar med andra i samma projekt.

Du kan lära dig mer om Git push och pull i vår separata handledning.

Vad är git status?

Kommandot git status visar det aktuella tillståndet för repositoriet i Git. Det ger information om vilka filer som har ändrats, vilka som ligger i staging inför nästa commit och vilka som är ostrackade. Det hjälper användare att följa arbetets framsteg och identifiera ändringar som behöver committas eller läggas i staging.

Vad är en commit i Git?

En commit representerar en ögonblicksbild av de ändringar som gjorts i filer i ett repository vid en viss tidpunkt. När du committar ändringar i Git sparar du i praktiken det aktuella tillståndet för dina filer och kan ange ett beskrivande meddelande som förklarar de gjorda ändringarna (vilket rekommenderas).

Varje commit skapar en unik identifierare som låter dig följa historiken över ändringar i repositoriet. Commits spelar en avgörande roll i versionshantering, eftersom de ger ett sätt att återgå till tidigare tillstånd i projektet, granska historiken och samarbeta med andra genom att dela uppdateringar.

Kolla in DataCamps Git-fusklapp för att hjälpa dig med intervjuförberedelserna

Vad är branching i Git?

Branching avser praktiken att avvika från huvudlinjen i utvecklingen (vanligen kallad main och tidigare kallad master) för att arbeta på nya funktioner, fixar eller experiment utan att påverka huvudkodbasen. Det gör att flera parallella utvecklingslinjer kan samexistera i samma repository.

Varje gren representerar en separat utvecklingslinje med sin egen uppsättning commits, vilket gör det möjligt för utvecklare att arbeta på olika funktioner eller fixar samtidigt. Branching underlättar samarbete, experimenterande och struktur i ett projekt, eftersom ändringar i en gren kan slås ihop tillbaka till huvudkodbasen när de är klara och testade.

Vad är en konflikt i Git?

Konflikter uppstår när motstridiga ändringar görs i samma del av en fil eller filer av olika bidragsgivare, vanligtvis under en merge- eller rebase-operation. Git kan inte automatiskt lösa dessa motstridiga ändringar och kräver manuell insats av användaren för att lösa skillnaderna.

För att lösa en konflikt, öppna den berörda filen — Git markerar de motstridiga avsnitten med markörerna <<<<<<<, ======= och >>>>>>>. Redigera filen för att behålla rätt version, ta bort markörerna och kör sedan:

git add <resolved-file>
git commit

Vad är merge i Git?

Merging är en grundläggande operation i Git som underlättar samarbete och integrering av ändringar mellan olika grenar i ett projekt. En merge är alltså processen att kombinera ändringarna från olika grenar in i en enda gren, vanligtvis huvudgrenen (t.ex. master eller main).

En merge integrerar de ändringar som gjorts i en gren med en annan och resulterar i en ny commit som kombinerar historiken från båda grenarna. Du kan lära dig mer om hur du löser merge-konflikter i Git i vår separata handledning.

Mellanavancerade Git-intervjufrågor

Vad är en remote i Git?

En remote är ett repository som ligger på en server eller en annan dator för samarbete och koddelning med andra. Det fungerar som en central plats där utvecklare kan pusha sina lokala ändringar och hämta ändringar som andra har gjort.

Remotes sätts vanligtvis upp på värdplattformar som GitHub, GitLab eller Bitbucket och möjliggör distribuerad utveckling och lagarbete genom att erbjuda en gemensam plats för att lagra och synkronisera projektkod mellan flera bidragsgivare.

Hur återställer du en commit som redan har pushats och blivit publik?

Kommandot git revert <commit-hash> kan användas för att återställa en commit som redan har pushats och blivit publik.

Steg-för-steg-processen är följande:

1. Identifiera den commit du vill återställa genom att hitta dess commit-hash. Detta kan göras med kommandot git log för att visa commit-historiken och hitta den commit-hash du vill återställa.

2. När du har commit-hashen använder du kommandot git revert följt av commit-hashen för att skapa en ny commit som upphäver ändringarna som infördes av den angivna commiten. Till exempel:

git revert <commit-hash>

3. Git öppnar en textredigerare för att skapa ett commit-meddelande för revert:en. Du kan redigera meddelandet vid behov och sedan spara och stänga redigeraren.

4. Efter att ha sparat commit-meddelandet skapar Git en ny commit som i praktiken upphäver ändringarna som infördes av den angivna commiten. Denna nya commit läggs till i historiken och återställer därmed ändringarna som gjordes av den ursprungliga commiten.

5. Slutligen pushar du den nya commiten till fjärrepositoriet för att göra revert:en publik med följande kommando:

git push origin <branch-name> 

Att använda git revert skapar en ny commit som upphäver ändringarna som infördes av den ursprungliga commiten, vilket i praktiken återställer ändringarna utan att ändra commit-historiken. Detta är säkrare än git reset eller git amend, som kan ändra commit-historiken och orsaka problem för kollegor som redan har hämtat ändringarna.

Vad är git stash?

git stash är ett Git-kommando som tillfälligt lagrar ändringar i arbetskatalogen som inte är redo att committas. Det låter utvecklare spara sina modifieringar utan att committa dem till repositoriet.

Stashing är användbart när du byter gren men inte vill committa eller förlora dina ändringar. Senare kan du tillämpa de sparade ändringarna på din arbetskatalog eller plocka bort dem från stash-stacken för att fortsätta arbeta på dem.

Vad är git reflog?

git reflog är ett Git-kommando som används för att visa referensloggarna, som registrerar förändringar av HEAD-pekaren och historiken över commits som har checkats ut i repositoriet. Det ger en kronologisk lista över nyliga åtgärder som utförts i repositoriet, inklusive commits, checkouts, merges och resets.

Refloggen är användbar för att återställa förlorade commits eller grenar och för att förstå sekvensen av åtgärder som vidtagits i repositoriet.

Hur får du en befintlig Git-gren att spåra en fjärrgren?

För att få en befintlig Git-gren att spåra en fjärrgren kan du använda kommandot git branch med flaggan --set-upstream-to eller -u, följt av namnet på fjärrgrenen.

Syntaxen ser ut så här:

git branch --set-upstream-to=<remote-name>/<branch-name>

eller

git branch -u <remote-name>/<branch-name>

Avancerade Git-intervjufrågor

Hur hanterar du flera konfigurationer för olika projekt i Git?

För att hantera olika konfigurationer, använd kommandot git config tillsammans med flaggorna --global, --system eller --local för att justera konfigurationsinställningar på olika nivåer. Alternativt kan du använda includeIf i Git-konfigurationen för att inkludera specifika uppsättningar baserat på repositoriets sökväg.

Hur hanterar du stora filer med Git?

Att hantera stora filer i Git kan vara utmanande på grund av deras inverkan på repo-storlek och prestanda. Använd Git LFS för att lagra stora filer utanför Git-repositoriet samtidigt som lätta pekare till dem behålls i repositoriet. Detta minskar repositoriets storlek och förbättrar prestandan. Git LFS stöder olika lagringsleverantörer och integreras sömlöst i Git-arbetsflöden.

Vad används git submodule till och hur uppdaterar du en?

Kommandot git submodule hanterar externa beroenden inom ett Git-repository. Det låter dig inkludera externa repositories som submoduler i ditt huvudrepository. Detta är användbart när du vill inkludera kod från externa källor men hålla den separat från ditt huvudprojekts kodbas.

För att uppdatera en submodul i Git kan du använda följande steg:

1. Navigera till submodulens katalog i ditt huvudrepository.

2. Använd git fetch för att hämta de senaste ändringarna från submodulens fjärrepositorium.

3. Om du vill uppdatera till den senaste commiten på den gren som submodulen spårar kan du använda git pull.

4. Alternativt, om du vill uppdatera till en specifik commit eller gren kan du använda git checkout följt av önskad commit-hash eller grenens namn.

5. När du har uppdaterat submodulen till önskat tillstånd behöver du committa ändringarna i huvudrepositoriet för att återspegla den uppdaterade submodulens tillstånd.

Vad är git cherry-pick och när skulle du använda det?

git cherry-pick låter dig tillämpa en specifik commit från en gren på en annan, utan att merga in hela grenen.

git cherry-pick <commit-hash>

Det är också användbart när en commit av misstag gjordes på fel gren: cherry-picka den till rätt gren och revertera den sedan från där den inte ska vara.

Vad är git bisect och vad används det till?

git bisect är ett felsökningsverktyg som använder binärsökning för att hitta den specifika commit som introducerade en bugg. I stället för att manuellt checka ut commits en efter en talar du om för Git vilken commit som är "good" (buggfri) och vilken som är "bad" (har buggen), och Git checkar ut commits däremellan och halverar sökutrymmet varje gång tills den hittar den skyldiga.

git bisect start
git bisect bad                # current commit has the bug
git bisect good <commit-hash> # this older commit was fine
# Git checks out a commit in between; you test it, then:
git bisect good   # or git bisect bad
# repeat until Git identifies the first bad commit
git bisect reset  # return to original state when done

Detta är betydligt snabbare än manuell sökning i stora repositories med hundratals commits.

Vad är Git hooks och hur används de?

Git hooks är skript som körs automatiskt vid specifika punkter i Git-arbetsflödet. De ligger i katalogen .git/hooks/ i ett repository och kan skrivas i valfritt skriptspråk.

Det finns två typer:

• Klientsidiga hooks körs på din lokala maskin — till exempel pre-commit (körs innan en commit skapas) eller commit-msg (validerar formatet på commit-meddelandet).

• Serversidiga hooks körs på fjärrservern — till exempel pre-receive (körs innan pushade commits accepteras).

Ett vanligt användningsfall är att använda en pre-commit-hook för att automatiskt köra en linter eller testsvit innan en commit tillåts. Detta upprätthåller kodkvalitetsstandarder i teamet.

Observera att hooks inte kopieras när du klonar ett repository, så team som är beroende av dem delar dem vanligtvis via ett separat skript eller ett verktyg som pre-commit (Python-paketet).

Frågor om ofta förväxlade Git-koncept

Vad är skillnaden mellan git fetch och git pull?

Den huvudsakliga skillnaden mellan git fetch och git pull ligger i vad de gör och hur de uppdaterar det lokala repositoriet.

Kommandot git fetch hämtar ändringar från ett fjärrepositorium till det lokala repositoriet. Det uppdaterar de fjärrspårande grenarna (t.ex. origin/master) i det lokala repositoriet för att återspegla tillståndet i fjärrepositoriet, men det uppdaterar inte arbetskatalogen eller mergar några ändringar in i den aktuella grenen. Det innebär att du efter en fetch kan granska ändringarna som gjorts i fjärrepositoriet utan att påverka ditt lokala arbete.

Kommandot git pull hämtar också ändringar från ett fjärrepositorium, men går ett steg längre genom att hämta ändringar och slå samman dem i den aktuella grenen i ett steg. Det utför i praktiken en git fetch följt av en git merge för att införliva ändringarna från fjärrepositoriet i den aktuella grenen.

Vad gör git reset?

Kommandot git reset återställer nuvarande HEAD till ett angivet tillstånd. Det betyder att det kan användas för att ångra ändringar, ta bort filer från staging eller flytta HEAD-pekaren till en annan commit. Observera att det finns tre huvudlägen för git reset:

• --soft: Återställer HEAD-pekaren till en specifik commit och behåller ändringarna i staging. Filer förblir modifierade i arbetskatalogen så att du kan recommitta dem.

• --mixed: Återställer HEAD-pekaren till en specifik commit och tar bort ändringar från staging. Filer förblir modifierade i arbetskatalogen, men ändringarna ligger inte i staging för commit.

• --hard: Återställer HEAD-pekaren till en specifik commit och kastar alla ändringar i arbetskatalogen och staging-området. Använd med försiktighet eftersom det permanent raderar icke-committade ändringar.

Viktigt: Använd aldrig git reset --hard på commits som redan har pushats till en delad fjärrgren. Det skriver om historiken och orsakar allvarliga problem för kollegor som redan har hämtat dessa commits. Använd i stället git revert för publika commits.

Vad är betydelsen av git push --force-with-lease jämfört med git push --force?

git push --force-with-lease är ett mer försiktigt sätt att tvångspusha ändringar till ett fjärrepositorium än git push --force eftersom det förhindrar att du oavsiktligt skriver över ändringar som andra har gjort i fjärrepositoriet.

När du använder git push --force tvångspushar du dina ändringar till fjärrepositoriet oavsett om andra har uppdaterat det sedan din senaste fetch. Detta kan leda till att andra utvecklares arbete oavsiktligt går förlorat.

I kontrast är git push --force-with-lease ett säkrare alternativ. Det kontrollerar om fjärrgrenen du pushar till har uppdaterats av andra sedan din senaste fetch. Om fjärrgrenen har uppdaterats avvisas pushen, vilket förhindrar att du oavsiktligt skriver över andras ändringar.

Vad är git rebase och hur skiljer det sig från git merge?

Båda git rebase och git merge införlivar ändringar från en gren i en annan, men de gör det på olika sätt.

• git merge kombinerar historiken för två grenar genom att skapa en ny "merge-commit". Detta bevarar hela historiken över när grenar skildes och sammanfördes igen, vilket är användbart för spårbarhet och transparens i teamet.

• git rebase flyttar eller spelar upp commits från en gren ovanpå en annan och skapar en ren, linjär commit-historik utan merge-commits. Detta gör loggen lättare att läsa, men det skriver om commit-historiken. Därför är den gyllene regeln för rebase: rebase:a aldrig en gren som andra arbetar på.

Vad är skillnaden mellan git clone och git fork?

Kloning skapar en lokal kopia av ett fjärrepositorium på din maskin. Du är fortfarande kopplad till samma repository och kan pusha ändringar tillbaka (om du har behörighet).

git clone https://github.com/user/repo.git

Forkning är standardarbetsflödet för att bidra till open source-projekt där du inte har direkt skrivbehörighet till det ursprungliga repot.

Förberedelser inför en Git-intervju

Att presentera dina Git-kunskaper och din erfarenhet under intervjuer är avgörande för att visa din kompetens i versionshantering och samarbete i mjukvaruutvecklingsteam.

Låt oss titta på några tips du bör följa när du förbereder dig inför din tekniska intervju för att kommunicera dina Git-färdigheter effektivt:

Förstå grunderna i Git

Säkerställ att du har en solid förståelse för Git-grunderna, inklusive repositories, branching, merging, commits och grundläggande kommandon som pull, push, clone och commit. Denna grundläggande kunskap blir basen för din diskussion under intervjun. Det hjälper också om du förstår väsentliga principer som versionshantering och kan urskilja skillnaderna mellan Git och andra versionshanteringssystem.

Avslutningsvis, bekanta dig med olika Git-metodiker, såsom Git Flow, GitHub Flow och GitLab Flow. Bedöm för- och nackdelar med varje angreppssätt och identifiera situationer där de är mest användbara.

Vår kompletta guide till Git är en bra utgångspunkt för att bekanta dig med grunderna.

Skaffa praktisk erfarenhet

Ju mer du använder Git, desto mer befäster du dina kunskaper. Regelbunden övning ökar din vana vid olika kommandon och procedurer. Försök att integrera Git i ditt dagliga arbetsflöde för att få mer exponering. Se till att experimentera med att skapa grenar, slå ihop dem och lösa konflikter.

Om du är osäker på vilka projekt du ska arbeta med för att få praktisk erfarenhet av Git, är deltagande i open source-projekt via plattformar som GitHub ett utmärkt sätt att få förstahandserfarenhet av branschstandardens samarbetsverktyg och arbetsflöden.

Lär dig vanliga problem och hur du felsöker dem

Du kommer förr eller senare att stöta på problem när du använder Git. Några vanliga problem är merge-konflikter, detached HEAD-tillstånd, att återställa ändringar och att återhämta förlorade commits. Att diagnostisera Git-problem förbättrar felsökningsförmågan och främjar en djupare förståelse för Gits underliggande mekanismer.

Genom att aktivt felsöka och analysera felmeddelanden får du insikter i Gits interna funktion och utvecklar färdigheter i att identifiera och lösa problem effektivt. Detta proaktiva förhållningssätt minskar potentiella risker och bygger förtroende och expertis i att hantera arbetsflöden för versionshantering.

Öva på låtsasintervjuer

Genom att delta i låtsasintervjuer kan kandidater identifiera svagheter i sina Git-kunskaper och sin kommunikativa förmåga, vilket gör att de kan fokusera förberedelserna effektivt.

Dessutom erbjuder låtsasintervjuer värdefulla möjligheter för kandidater att vässa sin problemlösningsförmåga genom att hantera realistiska Git-relaterade scenarier och kodövningar. Denna praktiska övning hjälper kandidater att bygga självförtroende i sina Git-kunskaper och förbättrar deras förmåga att uttrycka sina tankar tydligt under intervjun.

Slutsats

Git är ett kraftfullt versionshanteringssystem som används i stor utsträckning inom mjukvaruutveckling för att hantera kodändringar, samarbeta med andra och upprätthålla projekthistorik. Förtrogenhet med Git är väsentlig i tekniska intervjuer eftersom det visar skicklighet i viktiga utvecklarverktyg och arbetsflöden, visar samarbetsförmåga och framhäver förmågan att hantera kod effektivt i teammiljöer.

Dessutom möjliggör förståelse för Git-koncept och kommandon effektiva versionshanteringsrutiner som säkerställer kodintegritet, projektkontinuitet och strömlinjeformade utvecklingsprocesser. Kunskap om Git är därför ovärderlig för blivande mjukvaruingenjörer och utvecklare som navigerar tekniska intervjuer och siktar på framgångsrika karriärer

För vidare lärande, kolla in följande resurser:

• Vad är Git? – Den kompletta guiden till Git
• GitHub- och Git-handledning för nybörjare
• GitHub-koncept
• Komplett Git-fusklapp