Top 40 GIT Interview-spørgsmål og svar i 2021

top 40 git interview questions

Mest populære GIT-interviewspørgsmål med svar og eksempler:

Denne informative vejledning inkluderer et sæt af de mest sandsynligt stillede spørgsmål i Git-interviews sammen med deres beskrivende svar. Disse spørgsmål vil helt sikkert hjælpe dig med at forberede dig på og knække ethvert Git-interview med succes.

Uanset om du er en novice eller en erfaren professionel, vil disse interviewspørgsmål om Git og detaljerede svar hjælpe dig med at berige din viden om emnet og udmærke sig ved dit arbejde såvel som interviews.

Lad os komme igang!!

Ofte stillede spørgsmål om GIT-interview

Nedenfor er nogle af de ofte stillede spørgsmål om GIT-interview til din reference.

Q # 1) Hvad er Git?

Svar: Git er et distribueret versionskontrolværktøj. Det er kompatibelt med distribuerede ikke-lineære arbejdsgange, da det giver datasikkerhed til opbygning af software af god kvalitet.

Git er gratis og open source. Det kan bruges til næsten enhver form for projekt, det være sig lille eller stor i størrelse. Git er kendt for sin store hastighed og effektivitet. Git-arkiver er meget nemme at finde og få adgang til. På grund af visse funktioner er Git meget fleksibel, sikker og kompatibel med dit system.

Q # 2) Hvad er et distribueret versionskontrolsystem?

Svar: En distribueret VCS er et system, der ikke er afhængig af en central server for at opbevare en projektfil og alle dens versioner. I distribueret VCS får hver samarbejdspartner eller udvikler en lokal kopi af hovedlageret, og dette kaldes en klon.

(billede kilde )

Som du kan se i ovenstående diagram, vedligeholder hver samarbejdspartner et lokalt lager på deres lokale maskiner. De kan forpligte og opdatere de lokale arkiver uden problemer.

Ved hjælp af en pull-operation kan en udvikler opdatere sit lokale lager med de seneste ændringer fra den centrale server. Ved hjælp af push-operationen kan de sende deres ændringer fra det lokale lager til den centrale server.

Q # 3) Hvem skabte Git?

Svar: Git blev oprettet af Linus Torvalds i 2005 på vej til at udvikle Linux Kernel.

Spørgsmål nr. 4) Hvilket sprog bruges i Git?

Svar: C er det underliggende programmeringssprog, hvor Git er skrevet. C-sprog gør Git hurtig ved at undgå runtime-omkostninger forbundet med andre programmeringssprog på højt niveau.

Q # 5) Hvad er fordelene / hovedfunktionerne ved Git?

Svar: Nedenfor er de forskellige f spisning af Git.

(i) Gratis og åben kilde:

Git udstedes under GPL's (General Public License) open source-licens. Du behøver ikke betale noget for at bruge Git.

Det er helt gratis. Da det er open source, kan du ændre kildekoden efter dine behov.

(ii) Hastighed:

Da du ikke er forpligtet til at oprette forbindelse til ethvert netværk for at udføre alle handlinger, udfører det alle opgaverne hurtigt. At få versionshistorik fra et lokalt lagret lager kan være hundrede gange hurtigere end at få det fra fjernserveren.

Git er skrevet i C, som er det underliggende programmeringssprog, der undgår runtime-omkostninger forbundet med andre sprog på højt niveau.

(iii) Skalerbar:

Git er meget skalerbar. Så hvis antallet af samarbejdspartnere stiger i den kommende tid, kan Git let imødekomme denne ændring.

På trods af at Git repræsenterer et helt arkiv, er de data, der holdes på klientsiden, meget små, da Git komprimerer alle de enorme data gennem en tabsfri kompressionsteknik.

hvad man skal åbne json filer med

(iv) Pålidelig:

Da hver samarbejdspartner har sit eget lokale arkiv, i tilfælde af et systemnedbrud, kan de mistede data genvindes fra et hvilket som helst af de lokale arkiver. Til enhver tid har du en sikkerhedskopi af alle dine filer.

(v) Sikker:

Git bruger SHA1 (Secure Hash-funktion) til at navngive og identificere objekter inde i dens lager. Hver artefakt og forpligtelse check-summeres og gendannes gennem sin kontrolsum under kassen.

Git-historikken gemmes på en måde, hvor id'et for en bestemt version (en forpligtelse i form af Git) er afhængig af den samlede udviklingshistorik, der løber op til denne forpligtelse. Når en filversion er skubbet til Git, er der ingen måde at ændre den uden at blive bemærket.

(vi) Økonomisk:

I tilfælde af et centraliseret versionskontrolsystem skal den centrale server være stærk nok til at deltage i anmodninger fra hele teamet. Dette er ikke et problem for mindre hold, men når holdet udvides, kan hardwarebegrænsningerne på serveren være en hindring for ydeevnen.

I tilfælde af distribuerede versionskontrolsystemer som Git kræver teammedlemmerne ikke interaktion med serveren, når de skal skubbe eller trække ændringer. Alle de tunge løft forekommer i klientenden, så serverhardwaren kan med sikkerhed holdes ganske enkel.

(vii) Understøtter ikke-lineær udvikling:

Git giver hurtig forgrening og fletning og indeholder bestemte værktøjer til at forestille sig og krydse en ikke-lineær udviklingshistorie. En grundlæggende opfattelse i Git er, at en ændring flettes oftere end den er skrevet, da den sendes på tværs af forskellige korrekturlæsere.

Git-grene er ekstremt lette. En gren i Git refererer kun til en enkelt forpligtelse. Den komplette grenstruktur kan oprettes ved hjælp af overordnede forpligtelser.

(viii) Let forgrening:

Filialstyring gennem Git er meget ligetil og let. Det kræver kun et par jiffies for at oprette, slette og flette grene. Funktionsgrene giver et isoleret miljø til hver ændring af din codebase.

Når en udvikler har brug for at begynde at arbejde på noget, uanset størrelsen på arbejdet, opretter de en ny gren. Dette sørger for, at mastergrenen konstant har en produktionskvalitetskode.

(ix) Distribueret udvikling:

Git giver hver udvikler en lokal kopi af hele udviklingshistorikken plus ændringerne klones fra et sådant lager til et andet. Disse ændringer introduceres som tilføjede udviklingsgrene og kan flettes på samme måde som en lokalt udviklet gren.

(x) Kompatibilitet sammen med nuværende systemer eller protokol:

Repositories kan offentliggøres via HTTP, FTP eller en Git-protokol oven på enten en almindelig stikkontakt eller ssh.

Spørgsmål nr. 6) Hvordan opretter du et lager i Git?

Svar: For at oprette et arkiv skal du oprette en mappe til projektet, hvis det ikke allerede findes, og derefter blot udføre kommandoen “ git init ”. Ved at udføre denne kommando oprettes der en .git-mappe inde i projektmappen, dvs. nu er din projektmappe blevet til et Git-arkiv.

Q # 7) Hvad er en .git Directory?

Svar: I det øjeblik du opretter et lager, finder du et .git-bibliotek til stede inde i det. Denne .git-mappe indeholder alle metadata fra lageret og vedligeholder et spor over alle de ændringer, der er foretaget i filerne i dit lager, ved at holde en forpligtelseshistorik.

Alle oplysninger om forpligtelser, kroge, refs, objektdatabaser, eksterne lageradresser osv. Opbevares i denne mappe. Dette er den mest afgørende del af Git. Når du kloner et hvilket som helst Git-lager på din lokale maskine, er denne .git den mappe, der faktisk bliver kopieret.

Q # 8) Hvad sker der, hvis .git-biblioteket bliver slettet?

Svar: Hvis .git / biblioteket slettes, mister du oversigten over dit projekts historie. Datalageret vil ikke længere være under versionskontrol.

Q # 9) Hvilken kommando bruges til at skrive en Commit Message i Git?

Svar: Kommandoen, der bruges til at videregive en besked til en git commit er git commit -m “commit message”. Flaget m bruges til at videregive en kommitteringsbesked.

Q # 10) Hvad er det bare Git-arkiv? Hvordan adskiller det sig fra et standard / ikke-bare Git-arkiv?

Svar: Opbevaringssteder, der oprettes gennem git init kommando er standard / ikke-bare Git-arkiver.

I den øverste mappe i et sådant arkiv finder du to ting:

1. En .git-underkatalog, der holder alle metadata og sporer historien om din repo.
2. Et arbejdende træ.

De arkiver, der oprettes ved hjælp af git init –bare kommando er kendt som bare Git-arkiver. De bruges hovedsageligt til deling. De indeholder ikke noget arbejdstræ. De gemmer git-revisionshistorikken for dit arkiv i rodmappen i stedet for at have den inde i .git-undermappen.

Det indeholder bare nøgledata. Sådan adskiller et bare Git-arkiv sig fra et standard Git-arkiv. Et blankt lager har heller ikke en standard fjernbetjening oprindelse arkiv, da det fungerer som et oprindelsesregister for flere fjernbrugere.

Da et blankt lager ikke indeholder noget arbejdsområde, er git push og git pull kommandoer fungerer ikke over en ren repo. Du er ikke forpligtet til at foretage ændringer i en ren repo.

Q # 11) Nævn nogle Git Repository Hosting Services.

Svar:

• Github
• Pikacode
• Gitlab
• Microsoft VSTS
• BitBucket
• GitEnterprise
• SourceForge
• Affyringsrampe
• Perforce
• Bønnestængel
• Det ser ud som om

Q # 12) Navngiv nogle grundlæggende operationer i Git.

Svar: Nogle grundlæggende operationer i Git inkluderer:

• Initialiser
• Tilføje
• Begå
• Skubbe
• Trække

Q # 13) Navngiv nogle avancerede operationer i Git.

Svar: Nogle avancerede operationer i Git er:

• Forgrening
• Fletning
• Rebasing

Spørgsmål nr. 14) Hvordan skelner du mellem Git og SVN?

Svar: Git er en distribueret versionskontrol, mens SVN er centraliseret. Dette fører til mange forskelle mellem de to med hensyn til deres funktioner og funktioner.

hvilket site giver en gennemgang af registreringsdatabasen rengøringssoftware

Spørgsmål nr. 15) Hvordan skelner du mellem Git og GitHub?

Svar: Git er et versionskontrolsystem af høj kvalitet. Det distribueres i naturen og bruges til at spore ændringer i kildekoden gennem softwareudvikling. Det har en unik forgreningsmodel, der hjælper med at synkronisere arbejde blandt udviklere og spore ændringer i eventuelle filer.

De primære mål for Git er hastighed, dataintegritet, support til distribuerede, ikke-lineære arbejdsgange. Git installeres og vedligeholdes på den lokale maskine i stedet for skyen.

GitHub er en cloudbaseret Git repository-hostingtjeneste, der bringer hold sammen. Det giver dig en webbaseret GUI samt giver adgangskontrol og mange samarbejdsfunktioner, grundlæggende værktøjer til opgavestyring til hvert projekt.

GitHub er også en open source, dvs. kode holdes på en central server og kan tilgås af alle.

Spørgsmål nr. 16) Hvad er en konflikt i Git og hvordan man løser den?

Svar: Git har en automatisk fletningsfunktion, der håndterer fusionen på egen hånd, forudsat at kodeændringerne er sket på forskellige linjer og i forskellige filer.

Men i tilfælde af at konkurrere om forpligtelser, hvor der er ændringer i de samme kodelinjer i en fil, eller en fil er blevet slettet i en gren, men eksisterer og ændres i en anden, er Git ikke i stand til automatisk at løse forskelle og rejser således sammenfletningskonflikt.

I sådanne tilfælde kræver det din hjælp til at beslutte, hvilken kode der skal medtages, og hvilken kode, der skal bortskaffes i den endelige fusion.

En fusionskonflikt kan forekomme under sammenlægning af en gren, omlægning af en gren eller kirsebærplukning af en forpligtelse. Når en konflikt er opdaget, fremhæver Git det konfliktede område og beder dig om at løse det. Når konflikten er løst, kan du fortsætte med fusionen.

Følg nedenstående trin for at løse en konkurrerende fusionskonflikt med linjeskift:

1. Åbn Git Bash (Git kommandolinje).
2. Brug CD kommando til at gå til det lokale Git-arkiv, der har sammenlægningskonflikten.
3. Brug git-status kommando til at producere listen over filer, der er berørt af fletkonflikten.
4. Åbn teksteditoren, du bruger, og krydse til den fil, der har sammenfletningskonflikter.
5. For at se starten på fletkonflikten i din fil skal du se i dokumentet efter konfliktmarkøren<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> AFDELING-NAVN.
6. Vælg i tilfælde af, at du kun behøver at holde din gren ændringer, bare holde den anden gren ændringer eller foretage en ny ændring, der kan omfatte ændringer fra de to grene. Slet konfliktmarkørerne<<<<<<>>>>>> og foretag de ændringer, du har brug for i den endelige fusion.
7. Brug tilføjer git. kommando for at tilføje eller iscenesætte dine ændringer.
8. Endelig skal du bruge git commit -m “besked” kommando til at foretage dine ændringer med en kommentar.

For at løse den fjernede filfletningskonflikt skal du følge nedenstående trin:

1. Åbn Git Bash (Git kommandolinje).
2. Brug CD kommando til at gå til det lokale Git-arkiv, der har fletkonflikten.
3. Brug git-status kommando til at producere listen over filer, der er berørt af fletkonflikten.
4. Åbn teksteditoren, du bruger, og krydse til den fil, der har sammenfletningskonflikter.
5. Vælg, om du vil beholde den fjernede fil. Du kan kontrollere de seneste ændringer i den fjernede fil i din teksteditor.
6. Brug git add kommando for at tilføje den fjernede fil tilbage til lageret. Eller brug gå rm kommando for at fjerne filen fra dit lager.
7. Endelig skal du bruge git commit -m “besked” kommando til at foretage dine ændringer med en kommentar.

Spørgsmål nr. 17) Hvordan løser du et brudt engagement?

Svar: For at rette en brudt forpligtelse eller ændre den sidste forpligtelse er den mest bekvemme metode at bruge kommandoen “ git commit -amend ' .

Det giver dig mulighed for at kombinere iscenesatte ændringer med den tidligere forpligtelse som et alternativ til at oprette en helt ny forpligtelse. Dette erstatter den seneste forpligtelse med den ændrede forpligtelse.

(billede kilde )

Gennem denne kommando kan du også redigere den forrige forpligtelsesmeddelelse uden at ændre snapshotet.

Spørgsmål nr. 18) Hvad er brugen af ​​git instaweb?

Svar: Det er et script, hvorigennem du øjeblikkeligt kan gennemse dit fungerende Git-arkiv i en webbrowser.

Dette script opretter gitweb og en webserver til at gennemse det lokale lager. Den dirigerer automatisk en webbrowser og kører en webserver gennem en grænseflade ind i dit lokale lager.

Spørgsmål nr. 19) Hvad er git is-tree?

Svar: 'Git is-tree' betyder et træobjekt, der omfatter tilstanden og navnet på alle elementer sammen med SHA-1-værdien for klodsen eller træet.

Q # 20) Er der en måde at tilbageføre en git-forpligtelse, der allerede er skubbet og offentliggjort?

Svar: Ja, for at rette eller tilbageføre en dårlig forpligtelse er der to tilgange, der kan bruges baseret på scenariet.

De er:

1. Den meget åbenlyse måde er at foretage en ny forpligtelse, hvor du fjerner den dårlige fil eller retter fejlene i den. Når du er færdig, kan du skubbe det til et eksternt lager.
2. En anden tilgang er at oprette en ny forpligtelse for at fortryde alle ændringer, der blev foretaget i den tidligere dårlige forpligtelse. Dette kan gøres ved hjælp af git revert-kommando - “ git tilbagevenden '

Q # 21) Hvordan skelner du mellem git pull og git fetch?

Svar: Git pull kommando trækker alle nye forpligtelser fra en bestemt gren i det centrale lager og gør målgrenen i dit lokale lager opdateret.

Git hent sigter også mod den samme ting, men dens underliggende funktionalitet er lidt anderledes. Når du foretager en git-hentning, trækkes alle de nye forpligtelser fra en bestemt gren i dit centrale arkiv, og disse ændringer gemmes i en ny gren i dit lokale arkiv. Dette kaldes en hentet gren.

Hvis du ønsker at se disse ændringer i din målfilial, skal du udføre en gå flet efter git-hentning. Målgrenen opdateres kun med de seneste ændringer, efter at den er flettet med den hentede gren.

Så en git pull opdaterer den lokale filial med sin fjernversion, mens en git-hentning ikke direkte ændrer din egen lokale filial eller arbejdskopi under refs / hoveder. Git-hentning kan bruges til at opdatere dine fjernsporingsgrene under refs / fjernbetjeninger //.

Med enkle ord, git pull er lig med git-hentning efterfulgt af en git-fletning .

Spørgsmål nr. 22) Hvad er brugen af ​​iscenesættelsesområde eller indeksering i Git?

Svar: Fra Gits perspektiv er der tre områder, hvor filændringerne kan opbevares, dvs. arbejdskatalog, iscenesættelsesområde og lager.

Først foretager du ændringer i dit projekts arbejdsmappe, der er gemt på dit computers filsystem. Alle ændringer forbliver her, indtil du føjer dem til et mellemliggende område kaldet iscenesættelsesområde.

Du kan iscenesætte ændringerne ved at udføre git add. kommando. Dette iscenesættelsesområde giver dig en forhåndsvisning af din næste forpligtelse og lader dig grundlæggende finjustere dine forpligtelser. Du kan tilføje eller fjerne ændringer i mellemstationer, indtil du er tilfreds med den version, du vil begå.

Når du har bekræftet dine ændringer og tilmeldt den ændrede scene, kan du endelig begå ændringerne. Når de begår sig, går de det lokale lager, dvs. i .git / objects-biblioteket.

Hvis du bruger Git GUI, vil du se muligheden for at gennemføre dine ændringer. I nedenstående skærmbillede er filen sample.txt under ustagede ændringer, hvilket betyder, at den er i din arbejdsmappe.

Du kan vælge en fil og klikke på 'sceneændret', så flyttes den i iscenesættelsesområdet. For eksempel , filen hello.txt er til stede i faseændret (vil forpligte) område. Du kan bekræfte dine ændringer og derefter foretage en aflogning efterfulgt af en forpligtelse.

Staging kaldes også indeksering, fordi git vedligeholder en indeksfil for at holde styr på dine filændringer på tværs af disse tre områder. De filer, der er iscenesat, er i øjeblikket i dit indeks.

Når du tilføjer ændringer til mellemstationer, opdateres oplysningerne i indekset. Når du foretager en forpligtelse, er det faktisk, hvad der er i indekset, der bliver begået, og ikke hvad der er i arbejdsmappen. Du kan bruge git-status kommando for at se, hvad der er i indekset.

Spørgsmål nr. 23) Hvad er Git Stash?

Svar: GIT stash registrerer den aktuelle tilstand for arbejdsmappen og indekset og holder den på stakken til fremtidig brug. Det gendanner de ikke-forpligtede ændringer (både iscenesat og ikke-iscenesat) fra din arbejdsmappe og giver dig et rent arbejdstræ.

Du kan arbejde på noget andet nu, og når du kommer tilbage, kan du genanvende disse ændringer. Så hvis du vil skifte fra en kontekst til en anden uden at miste dine nuværende ændringer, kan du bruge stashing.

Det er nyttigt ved hurtig kontekstskift, hvor du er midt i en kodeændring, som du ikke vil foretage eller fortryde den lige nu, og du har noget andet at arbejde på. Kommandoen til at bruge er git stash.

Spørgsmål nr. 24) Hvad er Git Stash-dråben?

Svar: Når du ikke længere har brug for et bestemt stash, kan du fjerne det ved at udføre det kommandoen git stash drop . Hvis du vil fjerne alle stash på én gang fra arkivet, kan du køre git stash clear kommando .

Spørgsmål nr. 25) Hvad gælder Git stash? Hvordan adskiller det sig fra Git stash pop?

Svar: Begge kommandoer bruges til at genanvende dine stashede ændringer og begynde at arbejde fra det sted, du havde forladt.

I git stash gælder kommandoen, ændringerne vil blive anvendt igen på din arbejdskopi og vil også blive gemt i lageret. Denne kommando kan bruges, når du vil anvende de samme forskudte ændringer i flere grene.

I git stash pop kommandoen fjernes ændringerne fra stashet og genanvendes på arbejdskopien.

Q # 26) Hvad er brugen af ​​git clone command?

Svar: Det git klon kommando opretter en kopi af det eksisterende centrale Git-arkiv til din lokale maskine.

Spørgsmål nr. 27) Hvornår bruges kommandoen git config?

Svar: Det git config kommando bruges til at indstille konfigurationsindstillinger til din Git-installation.

For eksempel, efter at du har downloadet Git, skal du bruge nedenstående konfigurationskommandoer til at konfigurere brugernavn og begå e-mail-adresse i henholdsvis Git:

$ git config –global bruger.navn “”

$ git config –global user.email “”

Så primært kan ting som arkivets opførsel, brugerinformation og præferencer indstilles ved hjælp af denne kommando.

Spørgsmål nr. 28) Hvordan identificerer du, om filialen allerede er flettet til master?

Svar:

Ved at udføre nedenstående kommandoer kan du lære grenens fletningsstatus at kende:

1. git gren – sammensmeltet mester: Dette viser alle de grene, der er omdøbt til master.
2. git gren –smeltet: Dette viser en liste over alle de grene, der er blevet flettet ind i HEAD.
3. git gren – ikke-fusioneret: Dette viser alle de grene, der endnu ikke er slået sammen.

Som standard fortæller denne kommando kun fletningsstatus for lokale grene. Hvis du vil vide om både lokal og ekstern filmsammenlægningsstatus, kan du bruge -til flag. Hvis du kun vil tjekke for eksterne grene, kan du bruge -r flag.

Spørgsmål nr. 29) Hvad er kroge i Git?

Svar: Git kroge er visse scripts, som Git kører før eller efter en begivenhed som begå, skub, opdater eller modtag. Du finder mappen 'hooks' inde i .git-biblioteket i dit lokale arkiv. Du finder de indbyggede scripts her pre-commit, post-commit, pre-push, post push.

Disse scripts udføres lokalt før eller efter en begivenheds forekomst. Du kan også ændre disse scripts efter dine behov, og Git udfører scriptet, når den særlige begivenhed finder sted.

Spørgsmål nr. 30) Hvad er brugen af ​​gitgaffel? Hvordan adskiller gaffel sig fra kloning?

Svar: At forkaste et projekt betyder at oprette en ekstern kopi på serversiden af ​​det originale lager. Du kan omdøbe denne kopi og begynde at lave et nyt projekt omkring dette uden at påvirke det originale projekt. Gaflen er ikke kernekonceptet for Git.

Gaffeloperationen bruges af Git-workflow, og denne idé eksisterer længere for gratis og open source-software som GitHub. Når du først har forked projektet, vil du normalt sjældent bidrage til det overordnede projekt igen.

For eksempel, OpenBSD er et Unix-lignende open-source operativsystem, der blev udviklet af forking NetBSD, som er et andet Unix-lignende open source OS.

Imidlertid findes der i gafflen en direkte forbindelse mellem din gaffelkopi og det originale lager. Du kan når som helst bidrage tilbage til det oprindelige projekt ved hjælp af pull-anmodningerne.

I den forgrenede kopi kopieres alle hoveddata som koder og filer fra det originale lager, men grene, pull-anmodninger og andre funktioner bliver ikke kopieret. Forking er en ideel måde til open source-samarbejde.

Kloning er i det væsentlige et Git-koncept. En klon er en lokal kopi af ethvert eksternt lager. Når vi kloner et lager, kopieres hele kildelageret sammen med dets historie og grene til vores lokale maskine.

I modsætning til forking er der ingen direkte forbindelse mellem det klonede lager og det originale eksterne lager. Hvis du vil foretage pull-anmodninger og fortsætte tilbage til det oprindelige projekt, skal du få dig selv tilføjet som en samarbejdspartner i det originale lager.

Kloning er også en fantastisk måde at oprette en sikkerhedskopi af det originale arkiv, da den klonede kopi også har al forpligtelseshistorik.

Spørgsmål nr. 31) Hvordan finder du ud af, hvad alle filer er blevet ændret i en bestemt Git-forpligtelse?

Svar: Ved at bruge hash-værdien for den bestemte forpligtelse kan du udføre kommandoen nedenfor for at få listen over filer, der er blevet ændret i en bestemt forpligtelse:

git diff-tree -r {hash}

Dette viser alle de filer, der er blevet ændret, og også de filer, der er tilføjet. Flagget -r bruges til at liste individuelle filer sammen med deres sti i stedet for kun at skjule dem i deres rodkatalognavne.

Du kan også bruge nedenstående kommando:

git diff-tree –no-commit-id –name-only -r {hash}

–No-commit-id vil omskole de forpligtede hash-numre for at komme i output. Mens -name ekskluderer filstierne og kun giver filnavne i output.

Q # 32) Hvad er forskellen mellem git checkout (grennavn) og git checkout -b (grennavn)?

Svar: Kommandoen git checkout (filialnavn) skifter fra en gren til en anden.

Kommandoen git checkout -b (filialnavn) opretter en ny gren og skifter også til den.

Spørgsmål nr. 33) Hvad er SubGit?

Svar: SubGit er et værktøj, der bruges til SVN til Git Migration. Det er udviklet af et firma kaldet TMate. Det konverterer SVN-arkiverne til Git og lader dig arbejde på begge systemer samtidigt. Det synkroniserer automatisk SVN med Git.

(billede kilde )

Du kan oprette et SVN || Git-spejl ved hjælp af dette værktøj. SubGit skal installeres på din Git-server. Det registrerer alle indstillingerne i dit eksterne SVN-lager, inklusive SVN-revisioner, grene og tags, og konverterer dem til Git-forpligtelser.

Det bevarer også historikken inklusive sporing af flette data.

Spørgsmål nr. 34) Kan du gendanne en slettet gren i Git?

Svar: Ja du kan. For at gendanne en slettet gren, skal du kende SHA fra toppen af ​​dit hoved. SHA eller hash er et unikt ID, som Git opretter med hver operation.

Når du sletter en gren, får du SHA vist på terminalen:

Slettet gren (var)

Du kan bruge nedenstående kommando til at gendanne den slettede gren:

git checkout -b

Hvis du ikke kender SHA til forpligtelsen på spidsen af ​​din gren, kan du først bruge gå reflog kommando for at kende SHA-værdien, og anvend derefter ovenstående checkout-kommando for at gendanne din filial.

Q # 35) Hvad er git diff kommando? Hvordan er det anderledes end git status?

Svar: Git diff er en kommando til flere anvendelser, der kan udføres for at vise forskellene mellem to vilkårlige forpligtelser, ændringer mellem arbejdstræet og en forpligtelse, ændringer mellem arbejdstræ & et indeks, ændringer mellem to filer, ændringer mellem indeks & et træ osv.

Det git-status kommando bruges til at inspicere et lager. Det viser tilstanden for arbejdsmappen og iscenesættelsesområdet. Den viser de filer, der er iscenesat, og som ikke er iscenesat, og de filer, der ikke er sporet.

Q # 36) Hvad indeholder et Commit-objekt?

Svar: Forpligtelsesobjektet indeholder træ-objekt-hash på øverste niveau, overordnet forpligter hash (hvis nogen), forfatter- og kommitteroplysninger, forpligtelsesdato og meddelelsesmeddelelse.

qa spørgsmål og svar til automatiseringsinterview

Du kan se dette gennem git log kommando.

Eksempel:

(billede kilde )

Spørgsmål nr. 37) Hvad er git cherry-pick? Hvad er scenarierne, hvor git cherry-pick kan bruges?

Svar: Git kirsebærpluk er en stærk kommando til at anvende de ændringer, der er introduceret af en eller flere eksisterende forpligtelser. Det giver dig mulighed for at vælge en forpligtelse fra en gren og anvende den på en anden.

git cherry-pick commitSha er den kommando, der bruges til kirsebærplukning. commitSha er commit-referencen.

Denne kommando kan bruges til at fortryde ændringer. For eksempel, hvis du ved en fejltagelse har forpligtet dig til en forkert gren, kan du tjekke den korrekte gren og kirsebærplukke forpligtelsen til, hvor den skal høre hjemme.

Det kan også bruges i teamsamarbejde. Der kan være scenarier, hvor den samme kode skal deles mellem to komponenter i produktet. I dette tilfælde, hvis en udvikler allerede har skrevet den kode, så kan den anden kirsebærplukke det samme.

Cherry-picking er også nyttigt i hotfixes med fejl, hvor en patch-commit kan kirsebærplukkes direkte i mastergrenen for at løse problemet så hurtigt som muligt.

Q # 38) Hvad bruges 'git reset' til? Hvad er standardtilstanden for denne kommando?

Svar: Git reset er en stærk kommando til fortrydelse af lokale ændringer i tilstanden af ​​en Git repo. Denne kommando nulstiller den aktuelle HEAD til det angivne trin.

Det nulstiller både indekset og arbejdskataloget til tilstanden for din sidste forpligtelse. Git reset har tre tilstande, dvs. blød, hård og blandet. Standardfunktionen er blandet.

Q # 39) Hvad er forskellen mellem 'HEAD', 'working tree' og 'index'?

Svar: Arbejdstræet eller arbejdsområdet er den mappe, der indeholder de kildefiler, som du i øjeblikket arbejder på.

Indekset er det iscenesatte område i Git, hvor forpligtelserne forberedes. Det ligger mellem forpligte og dit arbejdstræ. Git-indeks er en stor binær fil, der viser alle filer i den aktuelle gren, deres navne, sha1-kontrolsummer og tidsstempler.

Denne fil findes på /.git/index. HEAD er referencen eller markøren til den seneste forpligtelse i den aktuelle kassegren.

Spørgsmål nr. 40) Hvad er forskellen mellem rebase og fusion? Hvornår skal du rebase, og hvornår skal du fusionere?

Svar: Både rebase- og fletkommandoer bruges til at integrere ændringer fra en gren til en anden, men på en anden måde.

Som det ses i nedenstående to billeder, antag at du har forpligtelser (dette er før fletning / rebase). Efter fusionen får du resultatet som en kombination af forpligtelser. Det binder historierne for begge grene sammen og skaber et nyt 'merge commit' i funktionsgrenen.

På den anden side vil rebase flytte hele funktionsgrenen til at begynde på spidsen af ​​mastergrenen.

(billede kilde )

Forpligtelser vil se ud:

Omfordeling anbefales ikke til offentlige grene, da det skaber inkonsekvente opbevaringssteder. Omlægning er dog en god mulighed for private filialer / individuelle udviklere. Det er ikke særlig velegnet til gren-per-funktion-tilstand. Men hvis du har en filial pr. Udvikler-model, er rebasing ikke til skade.

Rebase er også en destruktiv operation, så dit udviklingsteam skal være dygtigt nok til at anvende det korrekt. Ellers kan engageret arbejde gå tabt.

Desuden er det lettere at tilbageføre en fusion end at tilbageføre en rebase. Så hvis du ved, at der kan være behov for tilbagevenden, skal du bruge fusionen.

Fusion fortsætter historien, som den er, mens rebase omskriver historien. Således, hvis du vil se historien fuldstændigt, som den opstod, skal du bruge fusionere.

Spørgsmål nr. 41) Hvad er syntaksen for genbasering?

Svar: Syntaksen for rebase-kommandoen er git rebase (new-commit)

Spørgsmål nr. 42) Hvordan vil du fjerne en fil fra Git uden at fjerne den fra dit lokale filsystem?

Svar: Du kan bruge indstillingen 'cache' til dette:

git rm -rf –cached $ FILES

Denne kommando fjerner filerne fra dit arkiv uden at slette dem fra din disk.

Spørgsmål nr. 43) Hvad er det almindelige forgreningsmønster i Git?

Svar: Det fælles forgreningsmønster er baseret på git-flow. Det har to hovedgrene, dvs. master og udvikling.

• Hovedgrenen indeholder produktionskoden. Al udviklingskoden flettes ind i mastergrenen på et eller andet tidspunkt.
• Udviklingsgrenen indeholder præproduktionskoden. Når funktionerne er afsluttet, flettes de til mastergrenen, generelt gennem en CI / CD-pipeline.

Denne model har også nogle understøttende grene, der bruges under udviklingscyklussen:

• Funktionsgrene / emnegrener: De bruges til at udvikle nye funktioner til kommende udgivelser. Det kan forgrene sig fra udviklingsgrenen og skal flettes tilbage til udviklingsgrenen. Generelt findes disse grene kun i udvikleropbevaringssteder og ikke i oprindelse.
• Hotfix-filialer: De bruges til ikke-planlagt produktionsudgivelse, når der er behov for at rette enhver kritisk fejl med det samme i live prod-versionen. De kan forgrene sig fra mester og skal flettes tilbage til at udvikle og mestre.
• Frigivelsesgrene: De bruges til forberedelse af ny produktionsudgivelse. Frigivelsesgrenen giver dig mulighed for at lave mindre fejlrettelser og forberede metadata til frigivelse. De kan forgrene sig fra udvikling og skal flettes tilbage til master og udvikles.

Konklusion

Vi er gået gennem de vigtige spørgsmål, der generelt stilles under Git-interviews i denne vejledning.

Dette vil ikke kun hjælpe dig med at forberede dig til kommende interviews, men vil også afklare dine git-koncepter.

Alt det bedste til dit interview!

Anbefalet læsning

• Interviewspørgsmål og svar
• Nogle interessante softwaretestinterviewspørgsmål
• Top 40 C Programmeringsinterview Spørgsmål og svar
• Top 40 populære J2EE interviewspørgsmål og svar, du bør læse
• ETL Testing Interview Spørgsmål og svar
• 20+ Ofte stillede spørgsmål og svar om udgangssamtaler
• Top spørgsmål om Oracle-formularer og rapporter
• Nogle vanskelige manuelle testspørgsmål og svar