top 40 git interview questions
Mest populære GIT-intervjuspørsmål med svar og eksempler:
Denne informative opplæringen inneholder et sett med de mest sannsynlige spørsmålene i Git-intervjuer sammen med deres beskrivende svar. Disse spørsmålene vil absolutt hjelpe deg med å forberede deg på og knekke ethvert Git-intervju med suksess.
Enten du er en nybegynner eller en erfaren profesjonell, vil disse intervjuspørsmålene på Git og detaljerte svar definitivt hjelpe deg med å berike din kunnskap om emnet og utmerke deg i arbeidet ditt samt intervjuer.
La oss komme i gang!!
Ofte stilte spørsmål om GIT-intervju
Nedenfor er noen av de ofte stilte spørsmålene om GIT-intervjuer som referanse.
Q # 1) Hva er Git?
Svar: Git er et distribuert versjonskontrollverktøy. Den er kompatibel med distribuerte ikke-lineære arbeidsflyter, da den gir datasikkerhet for å bygge programvare av god kvalitet.
Git er gratis og åpen kildekode. Den kan brukes til nesten alle slags prosjekter, det være seg små eller store. Git er kjent for sin store hastighet og effektivitet. Git-arkiver er veldig enkle å finne og få tilgang til. På grunn av visse funksjoner er Git svært fleksibel, sikker og kompatibel med systemet ditt.
Spørsmål 2) Hva er et distribuert versjonskontrollsystem?
Svar: En distribuert VCS er et system som ikke er avhengig av en sentral server for å beholde en prosjektfil og alle dens versjoner. I distribuert VCS får hver samarbeidspartner eller utvikler en lokal kopi av hovedregisteret, og dette kalles en klon.
[bilde kilde ]
Som du kan se i diagrammet ovenfor, har hver samarbeidspartner et lokalt lager på sine lokale maskiner. De kan forplikte og oppdatere de lokale arkivene uten problemer.
Ved hjelp av en pull-operasjon kan en utvikler oppdatere sitt lokale depot med de siste endringene fra den sentrale serveren. Ved hjelp av push-operasjonen kan de sende endringene fra det lokale depotet til den sentrale serveren.
Q # 3) Hvem skapte Git?
Svar: Git ble opprettet av Linus Torvalds i 2005 på vei til å utvikle Linux-kjernen.
Q # 4) Hvilket språk brukes i Git?
Svar: C er det underliggende programmeringsspråket som Git er skrevet i. C-språk gjør Git raskt ved å unngå runtime-omkostninger knyttet til andre programmeringsspråk på høyt nivå.
Spørsmål nr. 5) Hva er fordelene / hovedtrekkene ved Git?
Svar: Oppført nedenfor er de forskjellige f mat fra Git.
(i) Gratis og åpen kildekode:
Git utstedes under GPLs (General Public License) open source-lisens. Du trenger ikke betale noe for å bruke Git.
Det er helt gratis. Siden det er åpen kildekode, kan du endre kildekoden i henhold til dine behov.
(ii) Hastighet:
Ettersom det ikke kreves at du kobler til noe nettverk for å utføre alle handlingene, utfører den alle oppgavene raskt. Å skaffe versjonshistorikk fra et lokalt lagret depot kan være hundre ganger raskere enn å få det fra den eksterne serveren.
Git er skrevet i C, som er det underliggende programmeringsspråket som unngår runtime-omkostninger knyttet til andre språk på høyt nivå.
(iii) Skalerbar:
Git er svært skalerbar. Så hvis antall samarbeidspartnere øker i den kommende tiden, så kan Git lett imøtekomme denne endringen.
Til tross for at Git representerer et helt arkiv, er dataene som holdes på klientsiden veldig små ettersom Git komprimerer hele enorme data gjennom en tapsfri komprimeringsteknikk.
(iv) Pålitelig:
Ettersom hver samarbeidspartner har sitt eget lokale arkiv, i tilfeller av et systemkrasj, kan tapte data gjenopprettes fra et hvilket som helst av de lokale arkivene. Til enhver tid vil du ha en sikkerhetskopi av alle filene dine.
(v) Sikre:
Git bruker SHA1 (Secure Hash Function) til å navngi og identifisere objekter inne i depotet. Hver gjenstand og forpliktelse blir oppsummert og gjenopprettet gjennom sjekksummen under kassen.
Git-historikken lagres på en måte som ID-en for en bestemt versjon (en forpliktelse i form av Git) er avhengig av at den totale utviklingshistorikken løper opp til forpliktelsen. Når en filversjon er presset til Git, er det ingen måte å endre den uten å bli lagt merke til.
(vi) Economical:
I tilfelle et sentralisert versjonskontrollsystem, må den sentrale serveren være sterk nok til å delta på forespørsler fra hele teamet. Dette er ikke et problem for mindre lag, men når teamet utvides, kan maskinvarebegrensningene til serveren være et hinder for ytelse.
Når det gjelder distribuerte versjonskontrollsystemer som Git, krever ikke teammedlemmene interaksjon med serveren når de må presse eller trekke endringer. Alle tunge løft skjer i klientenden, og servermaskinvaren kan absolutt holdes ganske enkel.
(vii) Støtter ikke-lineær utvikling:
Git gir rask forgrening og sammenslåing og inneholder spesielle verktøy for å se for seg og krysse en ikke-lineær utviklingshistorie. En grunnleggende oppfatning i Git er at en endring vil bli slått sammen oftere enn den er skrevet da den sendes på tvers av forskjellige korrekturlesere.
Git Branches er ekstremt lette. En gren i Git refererer bare til en enkelt forpliktelse. Den komplette grenstrukturen kan opprettes ved hjelp av foreldreforpliktelser.
(viii) Enkel forgrening:
Grenadministrasjon gjennom Git er veldig grei og enkel. Det krever bare noen få skrap for å opprette, slette og slå sammen grener. Funksjonsgrener gir et isolert miljø til hver endring av kodebasen.
Når en utvikler trenger å begynne å jobbe med noe, uavhengig av størrelsen på arbeidet, oppretter de en ny gren. Dette sørger for at hovedgrenen kontinuerlig har en produksjonskvalitetskode.
(ix) Distribuert utvikling:
Git gir hver utvikler en lokal kopi av hele utviklingshistorikken, pluss at endringene blir klonet fra et slikt lager til et annet. Disse endringene introduseres som ekstra utviklingsgrener og kan slås sammen på samme måte som en lokalt utviklet gren.
(x) Kompatibilitet sammen med nåværende systemer eller protokoller:
Repositories kan publiseres via HTTP, FTP eller en Git-protokoll på toppen av enten en vanlig stikkontakt eller ssh.
Sp # 6) Hvordan lager du et depot i Git?
Svar: For å opprette et depot må du opprette en katalog for prosjektet hvis det ikke allerede eksisterer, og deretter bare utføre kommandoen “ git init ”. Ved å utføre denne kommandoen vil en .git-katalog opprettes i prosjektkatalogen, dvs. nå har prosjektkatalogen din blitt et Git-arkiv.
Q # 7) Hva er en .git Directory?
Svar: I det øyeblikket du oppretter et depot, finner du en .git-katalog som er inne i den. Denne .git-katalogen inneholder alle metadataene til depotet og opprettholder et spor over alle endringene som er gjort i filene i depotet ditt, ved å holde en forpliktelseshistorikk.
All informasjon om forpliktelser, kroker, refs, objektdatabaser, adresser til eksterne arkiver osv. Er lagret i denne mappen. Dette er den mest avgjørende delen av Git. Når du kloner noe Git-arkiv på din lokale maskin, er denne .git katalogen som faktisk blir kopiert.
Q # 8) Hva skjer hvis .git-katalogen blir slettet?
Svar: Hvis .git / katalogen blir slettet, mister du oversikten over prosjektets historie. Datalageret vil ikke lenger være under versjonskontroll.
Q # 9) Hvilken kommando brukes til å skrive en Commit Message i Git?
Svar: Kommandoen som brukes til å formidle en melding til en git commit er git commit -m “commit message”. Flagget m brukes til å formidle en forpliktende melding.
Q # 10) Hva er det bare Git-depotet? Hvordan er det forskjellig fra et standard / ikke-bare Git-depot?
Svar: Datalagre som er opprettet gjennom git init kommandoen er standard / ikke-bare Git-arkiver.
I toppnivåmappen til et slikt arkiv finner du to ting:
- En .git-underkatalog som holder alle metadata og sporer historien til repoen din.
- Et fungerende tre.
Lagringsplassene som er opprettet ved hjelp av git init –bare kommando er kjent som bare Git-arkiver. De brukes hovedsakelig til deling. De inneholder ikke noe fungerende tre. De holder git-revisjonshistorikken til depotet ditt i rotmappen i stedet for å ha den inne i .git-undermappen.
Den inneholder bare bare data. Dette er hvordan et bare Git-arkiv er forskjellig fra et standard Git-arkiv. Dessuten har et tomt arkiv ikke en standard fjernkontroll opprinnelse repository da det fungerer som et originaldepot for flere eksterne brukere.
implementere en koblet liste i java
Siden et tomt arkiv ikke inneholder noe arbeidsområde, blir git push og git pull kommandoer fungerer ikke over bare repo. Du er ikke pålagt å foreta noen endringer i en ren repo.
Q # 11) Nevn noen Git Repository Hosting Services.
Svar:
- Github
- Pikacode
- Gitlab
- Microsoft VSTS
- BitBucket
- GitEnterprise
- SourceForge
- LaunchPad
- Perforce
- Beanstalk
- Det ser ut som
Q # 12) Nevn noen grunnleggende operasjoner i Git.
Svar: Noen grunnleggende operasjoner i Git inkluderer:
- Initialiser
- Legg til
- Begå
- Trykk
- Dra
Q # 13) Nevn noen avanserte operasjoner i Git.
Svar: Noen avanserte operasjoner i Git er:
- Forgrening
- Sammenslåing
- Rebasing
Q # 14) Hvordan vil du skille mellom Git og SVN?
Svar: Git er en distribuert versjonskontroll mens SVN er sentralisert. Dette fører til mange forskjeller mellom de to når det gjelder funksjoner og funksjoner.
Gå | SVN | |
---|---|---|
Innhold | Kryptografisk SHA-1 Hash. | Ingen hash innhold. |
Serverarkitektur | Datamaskinen som Git har installert på fungerer både som klient og server. Hver utvikler har en lokal kopi av prosjektets fullstendige versjonshistorikk på sine individuelle datamaskiner. Git endringer skjer lokalt. Derfor er det ikke påkrevd at utvikleren er koblet til nettverket til enhver tid. Bare for push and pull-operasjoner, vil utviklere trenge internettforbindelse for å koble til ekstern server. | SVN har en egen klient og server. Det er ikke lokalt tilgjengelig. Du må være koblet til nettverket for å utføre noen handlinger. Også, i SVN, siden alt er sentralisert, så i tilfelle den sentrale serveren blir krasjet eller ødelagt, vil det resultere i hele tap av data for prosjektet. |
Forgrening | Git er mest foretrukket av utviklere på grunn av sin effektive forgreningsmodell. Git-grener er lette, men kraftige. De er bare referanser til en bestemt forpliktelse. Du kan opprette, slette eller endre en filial når som helst uten å påvirke andre forpliktelser. Så, gaffel, gren og sammenslåing er enkelt med Git. | SVN har en komplisert forgrenings- og sammenslåingsmodell og det er tidkrevende å administrere. I SVN genereres filialer som kataloger i depotet. Denne katalogstrukturen er hovedsakelig problematisk. Når grenen er klar, må du forplikte deg tilbake til kofferten. Siden du ikke er den eneste som slår sammen endringene, kan det hende at versjonen av lastebilen ikke blir sett på som utviklerens grener. Dette kan føre til konflikter, manglende filer og forvirrede endringer i grenen din. |
Adgangskontroll | Git antar at alle bidragsyterne har samme tillatelser. | SVN lar deg definere lese- / skrivetilgangskontroller på hvert og katalognivå. |
Revisjon | I Git blir endringene sporet på depotnivå. Git gidder ikke for mye med å opprettholde den nøyaktige historikken til endringene som er gjort i depotet ditt. Den distribuerte naturen til Git lar enhver samarbeidspartner endre noen del av deres lokale repos historie. Med Git er det vanskelig å finne en virkelig historie med endringer i kodebasen. For eksempel mister du historikken etter å gi nytt navn i Git. | I SVN blir endringene sporet på filnivå. SVN opprettholder en ganske konsistent og presis endringshistorikk. Du kan gjenopprette nøyaktig de samme dataene som det var når som helst i det siste. SVNs historie er permanent og alltid bestemt. |
Lagringskrav | Git og SVN lagrer dataene på samme måte. Diskplassbruken er lik for begge. Den eneste forskjellen kommer inn i bildet i tilfelle binære filer. Git er ikke vennlig mot binære filer. Den kan ikke håndtere lagring av store binære filer. | SVN har en xDelta komprimeringsalgoritme som fungerer for både binære filer og tekstfiler. Så SVN kan håndtere lagring av store binære filer på relativt mindre plass enn Git. |
Brukervennlighet | Både Git og SVN bruker kommandolinjen som primær brukergrensesnitt. Git brukes i stor grad av utviklere / tekniske brukere. | SVN brukes i stor grad av ikke-tekniske brukere da det er lettere å lære. |
Globalt revisjonsnummer | Ikke tilgjengelig | Tilgjengelig |
Sp # 15) Hvordan vil du skille mellom Git og GitHub?
Svar: Git er et høykvalitets versjonskontrollsystem. Den distribueres i naturen og brukes til å spore endringer i kildekoden gjennom programvareutvikling. Den har en unik forgreningsmodell som hjelper til med å synkronisere arbeidet blant utviklere og spore endringer i eventuelle filer.
java hvordan du fjerner et element fra en matrise
De primære målene for Git er hastighet, dataintegritet, støtte for distribuerte, ikke-lineære arbeidsflyter. Git installeres og vedlikeholdes på den lokale maskinen, i stedet for skyen.
GitHub er en skybasert Git repository hosting-tjeneste som bringer team sammen. Det gir deg et nettbasert GUI, samt tilgangskontroll og mange samarbeidsfunksjoner, grunnleggende verktøy for oppgavehåndtering for hvert prosjekt.
Også, GitHub er en åpen kildekode, dvs. at koden holdes på en sentralisert server og kan nås av alle.
Spørsmål nr. 16) Hva er en konflikt i Git og hvordan løser du den?
Svar: Git har en automatisk sammenslåingsfunksjon som håndterer sammenslåingen forplikter alene, forutsatt at kodeendringene har skjedd på forskjellige linjer og i forskjellige filer.
Men i tilfelle å konkurrere om forpliktelser der det er endringer i de samme kodelinjene i en fil eller en fil er blitt slettet i en gren, men eksisterer og endres i en annen, kan Git ikke automatisk løse forskjeller og øker dermed sammenslåingskonflikt.
I slike tilfeller krever det din hjelp å bestemme hvilken kode som skal inkluderes og hvilken kode som skal kastes i den endelige sammenslåingen.
En sammenslåingskonflikt kan oppstå under sammenslåing av en filial, omstart av gren eller kirsebærplukking av en forpliktelse. Når en konflikt er oppdaget, fremhever Git det konfliktområdet og ber deg løse den. Når konflikten er løst, kan du fortsette med sammenslåingen.
Følg trinnene nedenfor for å løse en konkurrerende sammenslåingskonflikt:
- Åpne Git Bash (Git kommandolinje).
- Bruk CD kommando om å gå til det lokale Git-depotet som har sammenslåingskonflikten.
- Bruke git status kommando for å produsere listen over filer som er berørt av sammenslåingskonflikten.
- Åpne tekstredigeringsprogrammet du bruker, og krysse til filen som har sammenslåtte konflikter.
- For å se starten på sammenslåingskonflikten i filen din, se i dokumentet etter konfliktmarkøren<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> FILJENAVN.
- Velg i tilfelle du trenger å beholde bare endringene i din gren, bare beholde den andre grenens endringer, eller foreta en ny endring, som kan omfatte endringer fra de to grenene. Slett konfliktmarkørene<<<<<<>>>>>> og gjør endringene du trenger i den endelige sammenslåingen.
- Bruk legger git til. kommando for å legge til eller iscenesette endringene.
- Til slutt, bruk git commit -m “melding” kommando om å begå endringene med en kommentar.
For å løse den slettede flisekonflikten, må du følge trinnene nedenfor:
- Åpne Git Bash (Git kommandolinje).
- Bruk CD kommandoen for å gå til det lokale Git-depotet som har sammenslåingskonflikten.
- Bruke git status kommando for å produsere listen over filer som er berørt av sammenslåingskonflikten.
- Åpne tekstredigeringsprogrammet du bruker, og krysse til filen som har sammenslåtte konflikter.
- Velg om du vil beholde den fjernede filen. Du kan sjekke de siste endringene som er gjort i den fjernede filen i tekstredigeringsprogrammet.
- Bruk git add kommando for å legge til den fjernede filen tilbake til depotet. Eller bruk gå rm kommando for å fjerne filen fra depotet ditt.
- Til slutt, bruk git commit -m “melding” kommando om å begå endringene med en kommentar.
Spørsmål nr. 17) Hvordan vil du fikse en ødelagt forpliktelse?
Svar: For å fikse en ødelagt forpliktelse eller for å endre den siste forpliktelsen, er den mest praktiske metoden å bruke kommandoen “ git commit -amend ' .
Det lar deg kombinere trinnvise endringer med forrige forpliktelse som et alternativ for å opprette en helt ny forpliktelse. Dette erstatter den siste forpliktelsen med den endrede forpliktelsen.
[bilde kilde ]
Gjennom denne kommandoen kan du også redigere forrige meldingsmelding uten å endre øyeblikksbildet.
Sp # 18) Hva er bruken av git instaweb?
Svar: Det er et skript som du umiddelbart kan bla gjennom ditt fungerende Git-arkiv i en nettleser.
Dette skriptet setter opp gitweb og en webserver for å bla gjennom det lokale depotet. Den dirigerer automatisk en nettleser og kjører en webserver gjennom et grensesnitt inn i ditt lokale depot.
Spørsmål nr. 19) Hva er git is-tree?
Svar: ‘Git is-tree’ betyr et treobjekt som inneholder modusen og navnet på alle elementene sammen med SHA-1-verdien på klattet eller treet.
Q # 20) Er det en måte å tilbakeføre en git-forpliktelse som allerede er blitt presset og offentliggjort?
Svar: Ja, for å fikse eller tilbakeføre en dårlig forpliktelse, er det to tilnærminger som kan brukes basert på scenariet.
De er:
- Den veldig åpenbare måten er å gjøre en ny forpliktelse der du fjerner den dårlige filen eller retter feilene i den. Når du er ferdig, kan du skyve den til et eksternt lager.
- En annen tilnærming er å opprette en ny forpliktelse for å angre alle endringer som ble gjort i forrige dårlige forpliktelse. Dette kan gjøres gjennom git revert-kommando - “ git revert '
Q # 21) Hvordan vil du skille mellom git pull og git fetch?
Svar: Git pull kommando trekker alle nye forpliktelser fra en bestemt gren i det sentrale depotet og gjør målgrenen i ditt lokale depot oppdatert.
Git hent satser også på det samme, men den underliggende funksjonaliteten er litt annerledes. Når du gjør en git-henting, blir alle de nye forpliktelsene fra en bestemt gren trukket i det sentrale depotet ditt, og disse endringene blir lagret i en ny gren i ditt lokale depot. Dette kalles en hentet gren.
Hvis du ønsker å se disse endringene i målgrenen din, må du utføre en gå flette etter git-henting. Målgrenen blir oppdatert med de siste endringene først etter at den er slått sammen med den hentede grenen.
Så, en git pull gjør den lokale avdelingen oppdatert med sin eksterne versjon, mens en git-henting ikke direkte endrer din egen lokale filial eller arbeidskopi under refs / heads. Git-henting kan brukes til å oppdatere dine eksterne sporingsgrener under refs / fjernkontroller //.
Med enkle ord, git pull er lik git henting etterfulgt av en git flette .
Q # 22) Hva er bruken av Staging-område eller indeksering i Git?
Svar: Fra Gits perspektiv er det tre områder der filendringene kan oppbevares, dvs. arbeidskatalog, iscenesettelsesområde og depot.
Først gjør du endringer i prosjektets arbeidskatalog som er lagret på datamaskinens filsystem. Alle endringene forblir her til du legger dem til et mellomliggende område som kalles iscenesettelsesområde.
Du kan iscenesette endringene ved å utføre git add. kommando. Dette iscenesettingsområdet gir deg en forhåndsvisning av din neste forpliktelse og lar deg i utgangspunktet finjustere forpliktelsene dine. Du kan legge til eller fjerne endringer i iscenesettingsområdet til du er fornøyd med versjonen du skal begå.
Når du har bekreftet endringene dine og logget av scenen endret, kan du endelig begå endringene. Ved forpliktelse går de det lokale depotet, dvs. inn i .git / objects-katalogen.
Hvis du bruker Git GUI, vil du se muligheten til å iscenesette endringene. I skjermbildet nedenfor er filen sample.txt under ustagede endringsområde, noe som betyr at den er i arbeidskatalogen din.
Du kan velge en fil og klikke på 'stage changed', så blir den flyttet i iscenesettingsområdet. For eksempel , filen hello.txt er til stede i trinnendret (vil forplikte) område. Du kan bekrefte endringene dine og deretter utføre en pålogging, etterfulgt av en forpliktelse.
Staging kalles også indeksering fordi git opprettholder en indeksfil for å holde rede på filendringene dine over disse tre områdene. Filene som er iscenesatt er for øyeblikket i indeksen din.
Når du legger til endringer i iscenesettelsesområdet, blir informasjonen i indeksen oppdatert. Når du gjør en forpliktelse, er det faktisk hva som er i indeksen som blir forpliktet, og ikke hva som er i arbeidskatalogen. Du kan bruke git status kommandoen for å se hva som er i indeksen.
Spørsmål nr. 23) Hva er Git Stash?
Svar: GIT stash fanger den nåværende tilstanden til arbeidskatalogen og indeksen og holder den på bunken for fremtidig bruk. Den reverserer de ikke-forpliktede endringene (både iscenesatt og ikke-iscenesatt) fra arbeidskatalogen din og gir deg et rent arbeids tre.
Du kan jobbe med noe annet nå, og når du kommer tilbake, kan du bruke disse endringene på nytt. Så hvis du vil bytte fra en kontekst til en annen uten å miste de nåværende endringene dine, kan du bruke stashing.
Det er nyttig når du raskt bytter kontekst, der du er midt i en kodeendring som du ikke vil begå eller angre den akkurat nå, og du har noe annet å jobbe med. Kommandoen å bruke er git stash.
Spørsmål nr. 24) Hva er Git Stash-dråpen?
Svar: Når du ikke lenger trenger et bestemt stash, kan du fjerne det ved å utføre git stash drop-kommando . Hvis du vil fjerne alle stashene på en gang fra depotet, kan du kjøre git stash clear kommando .
Sp # 25) Hva gjelder Git stash? Hvordan er det forskjellig fra Git stash pop?
Svar: Begge kommandoene brukes til å bruke de stashede endringene på nytt og begynne å jobbe der du hadde igjen.
I git stash gjelder kommandoen, vil endringene brukes på nytt på arbeidskopien din og vil også bli oppbevart. Denne kommandoen kan brukes når du vil bruke de samme stashede endringene på flere grener.
I git stash pop kommandoen, blir endringene fjernet fra stashen og brukes på nytt på arbeidskopien.
Spørsmål nr. 26) Hva er bruken av git clone command?
Svar: De git klon kommandoen oppretter en kopi av det eksisterende sentrale Git-depotet til din lokale maskin.
Spørsmål nr. 27) Når brukes git config-kommandoen?
Svar: De git config kommandoen brukes til å angi konfigurasjonsalternativer for Git-installasjonen.
For eksempel, etter at du har lastet ned Git, må du bruke under konfigurasjonskommandoer for å sette opp brukernavn og begå e-postadresse i henholdsvis Git:
$ git config –global user.name “”
$ git config –global user.email “”
Så, hovedsakelig, ting som oppbevaringen til depotet, brukerinformasjon og preferanser kan settes opp ved hjelp av denne kommandoen.
Spørsmål nr. 28) Hvordan vil du identifisere om grenen allerede er slått sammen til master?
Svar:
Ved å utføre kommandoene nedenfor, kan du bli kjent med grenens sammenslåingsstatus:
- git branch –merged master: Dette vil liste opp alle grenene som har blitt omdøpt til master.
- git gren –smeltet: Dette vil liste opp alle grenene som er slått sammen til HEAD.
- git branch –no-fusjonert: Dette vil liste opp alle grenene som ennå ikke er slått sammen.
Som standard forteller denne kommandoen flettestatus bare for lokale grener. Hvis du vil vite mer om både sammenslåingsstatus for lokal og ekstern gren, kan du bruke -til flagg. Hvis du bare vil se etter eksterne grener, kan du bruke -r flagg.
Spørsmål nr. 29) Hva er kroker i Git?
Svar: Git kroker er visse skript som Git kjører før eller etter en hendelse som begå, presse, oppdatere eller motta. Du finner 'kroker' -mappen i .git-katalogen i ditt lokale depot. Du finner innebygde skript her pre-commit, post-commit, pre-push, post push.
Disse skriptene blir utført lokalt før eller etter hendelsen. Du kan også endre disse skriptene i henhold til dine behov, og Git vil utføre skriptet når den spesielle hendelsen inntreffer.
Spørsmål nr. 30) Hva er bruken av gitgaffel? Hvordan er gafler forskjellig fra kloning?
Svar: Å forkaste et prosjekt betyr å opprette en ekstern kopi av serveren på det originale depotet. Du kan gi nytt navn til denne kopien, og begynne å gjøre et nytt prosjekt rundt dette uten å påvirke det opprinnelige prosjektet. Gaffelen er ikke kjernekonseptet til Git.
Gaffeldriften brukes av Git-arbeidsflyten, og denne ideen eksisterer lenger for gratis programvare med åpen kildekode som GitHub. Når du først har forked prosjektet, vil du sjelden bidra til foreldreprosjektet igjen.
For eksempel, OpenBSD er et Unix-lignende open source-operativsystem som ble utviklet av forking NetBSD, som er et annet Unix-lignende open source OS.
Imidlertid, i gaffelen, eksisterer det en direkte forbindelse mellom den gaffelte kopien og det originale depotet. Når som helst kan du bidra tilbake til det opprinnelige prosjektet ved å bruke pull-forespørslene.
I den gaffelte kopien kopieres alle hoveddataene som koder og filer fra det opprinnelige depotet, men filialer, trekkforespørsler og andre funksjoner blir ikke kopiert. Forking er en ideell måte for samarbeid med åpen kildekode.
Kloning er egentlig et Git-konsept. En klon er en lokal kopi av et hvilket som helst eksternt arkiv. Når vi kloner et depot, blir hele kildedepotet sammen med dets historie og grener kopiert til vår lokale maskin.
I motsetning til forking er det ingen direkte forbindelse mellom det klonede depotet og det opprinnelige eksterne depotet. Hvis du vil gjøre pull-forespørsler og fortsette tilbake til det opprinnelige prosjektet, bør du få deg selv lagt til som en samarbeidspartner i det opprinnelige depotet.
Kloning er også en fin måte å lage en sikkerhetskopi av det opprinnelige depotet, da den klonede kopien også har all forpliktelseshistorikk.
Spørsmål nr. 31) Hvordan vil du finne ut hva alle filene er endret i en bestemt Git-kommisjon?
Svar: Ved å bruke hashverdien til den bestemte forpliktelsen, kan du utføre kommandoen nedenfor for å få listen over filer som er endret i en bestemt forpliktelse:
git diff-tree -r {hash}
Dette vil liste opp alle filene som er endret, og også filene som er lagt til. Flagget -r brukes til å liste opp individuelle filer sammen med banen i stedet for å skjule dem bare i rotkatalognavnene.
Du kan også bruke kommandoen nedenfor:
git diff-tree –no-commit-id –name-only -r {hash}
–No-commit-id vil omskole kommisjonens hash-tall for å komme i utdataene. Mens -name ekskluderer filbanene og bare gir filnavnene i utdataene.
Sp # 32) Hva er forskjellen mellom git checkout [grennavn] og git checkout -b [grennavn]?
Svar: Kommandoen git checkout [filialnavn] vil bytte fra en gren til en annen.
Kommandoen git checkout -b [grennavn] vil opprette en ny gren og også bytte til den.
Q # 33) Hva er SubGit?
Svar: SubGit er et verktøy som brukes for SVN til Git Migration. Den er utviklet av et selskap som heter TMate. Den konverterer SVN-arkivene til Git og lar deg jobbe med begge systemene samtidig. Den synkroniserer SVN automatisk med Git.
[bilde kilde ]
Du kan lage et SVN || Git-speil ved hjelp av dette verktøyet. SubGit skal installeres på Git-serveren din. Den vil oppdage alle innstillingene til det eksterne SVN-depotet ditt, inkludert SVN-revisjoner, grener og koder, og konverterer dem til Git commits.
Det bevarer også historikken, inkludert sporing av flettedata.
Q # 34) Kan du gjenopprette en slettet gren i Git?
Svar: Ja det kan du. For å gjenopprette en slettet gren, bør du kjenne SHA fra toppen av hodet. SHA eller hash er en unik ID som Git oppretter ved hver operasjon.
Når du sletter en gren, vises SHA på terminalen:
Slettet gren (var)
Du kan bruke kommandoen nedenfor for å gjenopprette den slettede grenen:
git kassa -b
Hvis du ikke kjenner SHA for forpliktelsen på toppen av avdelingen din, kan du først bruke gå på nytt kommandoen for å kjenne SHA-verdien, og bruk deretter kommandoen for kassen ovenfor for å gjenopprette grenen din.
Q # 35) Hva er git diff kommando? Hvordan er det forskjellig fra git status?
Svar: Git diff er en flerbrukskommando som kan utføres for å vise forskjellene mellom to vilkårlige forpliktelser, endringer mellom arbeidstreet og en forpliktelse, endringer mellom arbeidstreet og en indeks, endringer mellom to filer, endringer mellom indeks og et tre, etc.
De git status kommandoen brukes til å inspisere et depot. Den viser tilstanden til arbeidskatalogen og iscenesettingsområdet. Den vil liste opp filene som er iscenesatt, som ikke er iscenesatt, og filene som ikke er sporet.
Q # 36) Hva inneholder et Commit-objekt?
Svar: Forpliktelsesobjektet inneholder toppobjekt-hash-hash, foreldre forplikter hash (hvis noen), forfatter- og pendlerinformasjon, forpliktelsesdato og forpliktelsesmelding.
Du kan se dette gjennom git logg kommando.
Eksempel:
[bilde kilde ]
Spørsmål nr. 37) Hva er git cherry-pick? Hva er scenariene der git cherry-pick kan brukes?
Svar: Git kirsebærplukk er en kraftig kommando for å bruke endringene introdusert av en eller flere eksisterende forpliktelser. Det lar deg velge en forpliktelse fra en gren og bruke den på en annen.
git cherry-pick commitSha er kommandoen som brukes til kirsebærplukking. commitSha er forpliktelsesreferansen.
Denne kommandoen kan brukes til å angre endringene. For eksempel, hvis du ved en feiltakelse har forpliktet deg til en feil gren, kan du sjekke ut den rette grenen og kirsebærplukke forpliktelsen til hvor den skal høre hjemme.
Den kan også brukes i lagsamarbeid. Det kan være scenarier der den samme koden må deles mellom to komponenter i produktet. I dette tilfellet, hvis en utvikler allerede har skrevet den koden, kan den andre kirsebærplukke den samme.
Cherry-picking er også nyttig i feilreparasjoner der en patch-forpliktelse kan kirsebærplukkes direkte inn i hovedgrenen for å løse problemet så snart som mulig.
Q # 38) Hva brukes ‘git reset’ til? Hva er standardmodus for denne kommandoen?
Svar: Git reset er en kraftig kommando for å angre lokale endringer i tilstanden til en Git repo. Denne kommandoen tilbakestiller gjeldende HEAD til det angitte trinnet.
Den tilbakestiller både indeksen og arbeidskatalogen til den siste forpliktelsen. Git reset har tre moduser, dvs. myk, hard og blandet. Standard driftsmodus er blandet.
Q # 39) Hva er forskjellen mellom 'HEAD', 'working tree' og 'index'?
Svar: Arbeidstreet eller arbeidsområdet er katalogen som inneholder kildefilene du jobber med.
Indeksen er iscenesettingsområdet i Git der forpliktelsene forberedes. Det ligger mellom forpliktelsen og arbeidstreet ditt. Git-indeks er en stor binær fil som viser alle filene i den nåværende grenen, navn, sha1-kontrollsummer og tidsstempler.
Denne filen er til stede på /.git/index. HEAD er referansen eller pekeren til den siste forpliktelsen i den nåværende kassen.
Q # 40) Hva er forskjellen mellom rebase og flette? Når skal du basere på nytt, og når skal du slå sammen?
Svar: Både kommandoer for rebase og flette brukes til å integrere endringer fra en gren til en annen, men på en annen måte.
Som du ser på de to bildene nedenfor, antar du at du har forpliktelser (dette er før fletting / rebase). Etter sammenslåingen får du resultatet som en kombinasjon av forpliktelser. Det binder sammen historiene til begge grenene og skaper en ny ‘merge commit’ i funksjonsgrenen.
På den annen side vil rebase flytte hele filialen for å begynne på toppen av mastergrenen.
[bilde kilde ]
Forpliktelser vil se ut som:
Rebasing anbefales ikke for offentlige filialer, da det skaper inkonsekvente depoter. Imidlertid er rebasing et godt alternativ for private filialer / individuelle utviklere. Det er ikke veldig godt egnet for gren-per-funksjon-modus. Men hvis du har en gren-per-utvikler-modell, er det ingen skade å rebase.
Rebase er også en destruktiv operasjon, så utviklingsteamet ditt bør være dyktig nok til å bruke den riktig. Ellers kan engasjert arbeid gå tapt.
Videre er det enklere å tilbakestille en sammenslåing enn å tilbakestille en rebase. Så hvis du vet at det kan være muligheter for tilbakestilling som kreves, bør du bruke fusjonen.
Merge fortsetter historien som den er, mens rebase omskriver historien. Dermed, hvis du vil se historien helt slik den skjedde, bør du bruke flette.
Spørsmål nr. 41) Hva er syntaksen for rebasering?
Svar: Syntaksen for rebase-kommandoen er git rebase [new-commit]
Spørsmål nr. 42) Hvordan vil du fjerne en fil fra Git uten å fjerne den fra det lokale filsystemet?
Svar: Du kan bruke alternativet 'hurtigbufret' for dette:
git rm -rf –cached $ FILES
Denne kommandoen vil fjerne filene fra depotet ditt uten å slette dem fra disken.
Q # 43) Hva er det vanlige forgreningsmønsteret i Git?
Svar: Det vanlige forgreningsmønsteret er basert på git-flow. Den har to hovedgrener, dvs. master og utvikling.
- Hovedgrenen inneholder produksjonskoden. All utviklingskoden slås sammen i hovedgrenen på et eller annet tidspunkt.
- Utviklingsgrenen inneholder pre-produksjonskoden. Når funksjonene er fullført, blir de slått sammen til hovedgrenen, vanligvis gjennom en CI / CD-rørledning.
Denne modellen har også noen støttegrener som brukes under utviklingssyklusen:
- Funksjonsgrener / emnegrener: De brukes til å utvikle nye funksjoner for kommende utgivelser. Det kan forgrene seg fra utviklingsgrenen og må slås sammen i utviklingsgrenen. Generelt eksisterer disse grenene bare i utviklerregister, og ikke i opprinnelse.
- Hurtigreparasjonsgrener: De brukes til ikke planlagt produksjonsutgivelse når det er behov for å fikse kritisk feil umiddelbart i live prod-versjonen. De kan forgrene seg fra mester og må slås sammen til utvikling og mestring.
- Utgivelsesgrener: De brukes til utarbeidelse av ny produksjonsutgivelse. Utgivelsesgrenen lar deg gjøre mindre feilrettinger og forberede metadata for utgivelse. De kan forgrene seg fra utvikling og må slås sammen til mester og utvikle seg.
Konklusjon
Vi har gått gjennom de viktige spørsmålene som vanligvis blir stilt under Git-intervjuer i denne opplæringen.
implementering av en stack c ++
Dette vil ikke bare hjelpe deg med å forberede deg på kommende intervjuer, men vil også avklare git-konseptene dine.
Alt det beste for intervjuet ditt!
Anbefalt lesing
- Intervju spørsmål og svar
- Noen interessante intervjusspørsmål om programvaretesting
- Topp 40 C-programmeringsintervju Spørsmål og svar
- Topp 40 populære J2EE intervjuspørsmål og svar du bør lese
- ETL Testing Intervju Spørsmål og svar
- 20+ Vanlige spørsmål om avslutningsintervju og spørsmål
- Top Oracle Forms and Reports Interview Questions
- Noen vanskelige manuelle testspørsmål og svar