Topp 40 GIT-intervjufrågor och svar 2021

top 40 git interview questions

Mest populära GIT-intervjufrågor med svar och exempel:

Denna informativa handledning innehåller en uppsättning av de mest troligt ställda frågorna i Git-intervjuer tillsammans med deras beskrivande svar. Dessa frågor kommer säkert att hjälpa dig att förbereda dig för och knäcka alla Git-intervjuer framgångsrikt.

Oavsett om du är en nybörjare eller en erfaren professionell, kommer dessa intervjufrågor om Git och detaljerade svar definitivt att hjälpa dig att berika din kunskap om ämnet och utmärka dig i ditt arbete såväl som intervjuer.

Låt oss börja!!

Vanliga frågor om GIT-intervju

Nedan listas några av de vanligaste frågorna från GIT-intervjun som referens.

F # 1) Vad är Git?

Svar: Git är ett distribuerat versionskontrollverktyg. Den är kompatibel med distribuerade icke-linjära arbetsflöden eftersom den erbjuder datasäkerhet för att bygga programvara av god kvalitet.

Git är gratis och öppen källkod. Det kan användas i nästan alla typer av projekt, vare sig det är litet eller stort. Git är känt för sin höga hastighet och effektivitet. Git-arkiv är mycket lätta att hitta och komma åt. På grund av vissa funktioner är Git mycket flexibel, säker och kompatibel med ditt system.

F # 2) Vad är ett distribuerat versionskontrollsystem?

Svar: En distribuerad VCS är ett system som inte är beroende av en central server för att behålla en projektfil och alla dess versioner. I distribuerad VCS får varje samarbetspartner eller utvecklare en lokal kopia av huvudförvaret och detta kallas en klon.

(bild källa )

Som du kan se i ovanstående diagram har varje medarbetare ett lokalt arkiv på sina lokala maskiner. De kan begå och uppdatera de lokala förvaren utan problem.

Med hjälp av en pull-operation kan en utvecklare uppdatera sitt lokala arkiv med de senaste ändringarna från centralservern. Med hjälp av push-operationen kan de skicka sina ändringar från det lokala förvaret till den centrala servern.

F # 3) Vem skapade Git?

Svar: Git skapades av Linus Torvalds 2005 på vägen för att utveckla Linux-kärnan.

F # 4) Vilket språk används i Git?

Svar: C är det underliggande programmeringsspråket där Git är skrivet. C-språk gör Git snabb genom att undvika runtime-omkostnader kopplade till andra programmeringsspråk på hög nivå.

F # 5) Vilka är fördelarna / huvudfunktionerna med Git?

Svar: Nedan listas de olika f mat från Git.

(i) Gratis & öppen källkod:

Git utfärdas under GPL: s (General Public License) öppen källkodslicens. Du behöver inte betala någonting för att använda Git.

Det är helt gratis. Eftersom det är öppen källkod kan du ändra källkoden efter dina behov.

(ii) Hastighet:

Eftersom du inte är skyldig att ansluta till något nätverk för att utföra alla åtgärder utför den alla uppgifter snabbt. Att få versionhistorik från ett lokalt lagrat arkiv kan vara hundra gånger snabbare än att få det från fjärrservern.

Git är skrivet i C, vilket är det underliggande programmeringsspråket som undviker runtime-omkostnader kopplade till andra språk på hög nivå.

(iii) Skalbar:

Git är mycket skalbar. Så om antalet medarbetare ökar under den kommande tiden kan Git enkelt tillgodose denna förändring.

Trots det faktum att Git representerar ett helt arkiv är informationen som hålls på klientsidan väldigt liten eftersom Git komprimerar hela den enorma datan genom en förlustfri komprimeringsteknik.

(iv) Pålitlig:

Eftersom varje samarbetspartner har sin egen lokala databas kan de förlorade uppgifterna återställas från någon av de lokala förvaren i fall av en systemkrasch. Du har alltid en säkerhetskopia av alla dina filer.

(v) Säkra:

Git använder SHA1 (Secure Hash-funktion) för att namnge och identifiera objekt i sitt förvar. Varje artefakt och åtagande kontrollsummeras och återställs genom sin kontrollsumma under utcheckningen.

Git-historiken sparas på ett sätt där ID för en specifik version (ett engagemang i termer av Git) förlitar sig på den totala utvecklingshistoriken som går fram till det åtagandet. När en filversion har skjutits till Git finns det inget sätt att ändra den utan att du märker det.

(vi) Ekonomiskt:

När det gäller ett centraliserat versionskontrollsystem måste den centrala servern vara tillräckligt stark för att kunna delta i förfrågningar från hela teamet. Detta är inte ett problem för mindre lag, men när teamet expanderar kan maskinvarubegränsningarna på servern vara ett hinder för prestanda.

När det gäller distribuerade versionskontrollsystem som Git behöver inte teammedlemmarna interaktion med servern förväntar sig när de måste skjuta eller dra ändringar. Alla tunga lyft sker i klientänden, så serverhårdvaran kan säkert hållas ganska enkel.

(vii) Stöder icke-linjär utveckling:

Git ger snabb förgrening och sammanslagning och innehåller särskilda verktyg för att föreställa sig och korsa en icke-linjär utvecklingshistoria. En grundläggande uppfattning i Git är att en förändring kommer att slås samman oftare än den skrivs eftersom den skickas över olika granskare.

Git Branches är extremt lätta. En gren i Git refererar bara till en enda förpliktelse. Den kompletta grenstrukturen kan skapas med hjälp av överordnade åtaganden.

(viii) Enkel förgrening:

Filthantering genom Git är mycket enkelt och enkelt. Det kräver bara några få jiffies för att skapa, ta bort och slå samman filialer. Funktionsgrenar ger en isolerad miljö för varje ändring av din kodbas.

När en utvecklare behöver börja arbeta med något, oavsett storleken på arbetet, skapar de en ny gren. Detta ser till att huvudgrenen ständigt har en produktionskvalitetskod.

(ix) Distribuerad utveckling:

Git ger varje utvecklare en lokal kopia av hela utvecklingshistoriken, plus ändringarna klonas från ett sådant arkiv till ett annat. Dessa förändringar introduceras som tillagda utvecklingsgrenar och kan slås samman på samma sätt som en lokalt utvecklad gren.

(x) Kompatibilitet tillsammans med nuvarande system eller protokoll:

Förvar kan publiceras via HTTP, FTP eller ett Git-protokoll ovanpå antingen ett vanligt uttag eller ssh.

F # 6) Hur skapar du ett arkiv i Git?

Svar: För att skapa ett arkiv måste du skapa en katalog för projektet om det inte redan finns och sedan bara utföra kommandot “ git init ”. Genom att utföra detta kommando skapas en .git-katalog i projektkatalogen, dvs. nu har din projektkatalog förvandlats till ett Git-arkiv.

F # 7) Vad är en .git-katalog?

Svar: När du skapar ett arkiv hittar du en .git-katalog som finns i den. Den här .git-katalogen innehåller alla metadata för förvaret och underhåller ett spår av alla ändringar som gjorts i filerna i ditt förvar genom att hålla en åtagandeshistorik.

All information om åtaganden, krokar, refs, objektdatabaser, fjärrförvarets adresser etc. förvaras i den här mappen. Detta är den viktigaste delen av Git. När du klonar något Git-arkiv på din lokala dator är den .git den katalog som faktiskt kopieras.

F # 8) Vad händer om .git-katalogen raderas?

Svar: Om .git / katalog raderas kommer du att tappa koll på projektets historik. Förvaret kommer inte längre att vara under versionskontroll.

F # 9) Vilket kommando används för att skriva ett Commit Message i Git?

Svar: Kommandot som används för att vidarebefordra ett meddelande till en git commit är git commit -m 'commit message'. Flaggan m används för att skicka ett kommit-meddelande.

F # 10) Vad är det bara Git-förvaret? Hur skiljer det sig från ett standard / icke-blott Git-arkiv?

Svar: Förvar som skapas genom git init kommandot är standard / icke-nakna Git-arkiv.

I den översta mappen på ett sådant arkiv hittar du två saker:

1. En .git-underkatalog som håller alla metadata och spårar din repos historia.
2. Ett fungerande träd.

Förvaren som skapas med git init –bar kommando är kända som bare Git-arkiv. De används främst för delning. De innehåller inget fungerande träd. De håller git-revisionshistoriken för ditt förvar i rotmappen snarare än att ha den i .git-undermappen.

Det innehåller bara nollförvardata. Så här skiljer sig ett bara Git-arkiv från ett standard Git-arkiv. Ett fritt arkiv har inte heller en standardfjärrkontroll ursprung förvar eftersom det fungerar som ett ursprung förvar för flera fjärranvändare.

Eftersom ett fritt arkiv inte innehåller någon arbetsyta, kommer git push och git pull kommandon fungerar inte över en ren repo. Du är inte skyldig att göra några ändringar i en ren repo.

F # 11) Nämn några tjänster för Git Repository Hosting.

Svar:

• Github
• Pikacode
• Gitlab
• Microsoft VSTS
• Bit hink
• GitEnterprise
• SourceForge
• Startplatta
• Ovillkorligen
• Beanstalk
• Det ser ut som

F # 12) Nämn några grundläggande funktioner i Git.

Svar: Några grundläggande funktioner i Git inkluderar:

• Initiera
• Lägg till
• Begå
• Skjuta på
• Dra

F # 13) Nämn några avancerade operationer i Git.

Svar: Några avancerade operationer i Git är:

• Förgrening
• Sammanfogning
• Omfasning

F # 14) Hur ska du skilja mellan Git och SVN?

Svar: Git är en distribuerad versionskontroll medan SVN är centraliserat. Detta leder till många skillnader mellan de två när det gäller deras funktioner och funktioner.

F # 15) Hur skiljer du mellan Git och GitHub?

Svar: Git är ett högkvalitativt versionskontrollsystem. Den distribueras i naturen och används för att spåra ändringar i källkoden under programvaruutveckling. Den har en unik förgreningsmodell som hjälper till att synkronisera arbetet mellan utvecklare och spåra ändringar i alla filer.

De primära målen för Git är hastighet, dataintegritet, stöd för distribuerade, icke-linjära arbetsflöden. Git installeras och underhålls på den lokala maskinen istället för molnet.

GitHub är en molnbaserad Git-förvaringstjänst som för samman team. Det ger dig ett webbaserat GUI samt ger åtkomstkontroll och många samarbetsfunktioner, grundläggande uppgiftshanteringsverktyg för varje projekt.

GitHub är också en öppen källkod, dvs kod hålls på en centraliserad server och kan nås av alla.

F # 16) Vad är en konflikt i Git och hur man löser den?

Svar: Git har en automatisk sammanslagningsfunktion som hanterar sammanslagningen på egen hand, förutsatt att kodändringarna har skett på olika rader och i olika filer.

Men om du tävlar om åtaganden där det finns förändringar i samma kodrader i en fil eller en fil har tagits bort i en gren men existerar och modifierats i en annan, kan Git inte automatiskt lösa skillnader och därmed väcka sammanslagningskonflikt.

startnivå qa testare intervju frågor

I sådana fall kräver det din hjälp att bestämma vilken kod som ska inkluderas och vilken kod som ska kastas i den slutliga sammanslagningen.

En sammanslagningskonflikt kan uppstå vid sammanslagning av en filial, omgränsning av en filial eller körsbärsplockning av ett engagemang. När en konflikt upptäcks framhäver Git det konfliktområdet och ber dig att lösa det. När konflikten är löst kan du gå vidare med sammanslagningen.

Följ stegen nedan för att lösa en konkurrerande sammanslagningskonflikt:

1. Öppna Git Bash (Git-kommandorad).
2. Använda sig av CD kommando för att gå till det lokala Git-arkivet som har sammanslagningskonflikten.
3. Använd git-status kommando för att producera listan över filer som påverkas av sammanslagningskonflikten.
4. Öppna textredigeraren som du använder och gå igenom filen som har sammanslagna konflikter.
5. För att se början på sammanslagningskonflikten i din fil, leta efter dokumentet för konfliktmarkören<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> BRANCH-NAME.
6. Välj i händelse av att du bara behöver behålla ändringarna i din gren, bara behålla den andra grenens ändringar eller göra en ny förändring, som kan innehålla ändringar från de två grenarna. Radera konfliktmarkörerna<<<<<<>>>>>> och gör de ändringar du behöver i den slutliga sammanslagningen.
7. Använda sig av tillägger git. kommando för att lägga till eller iscensätta dina ändringar.
8. Slutligen, använd git commit -m “meddelande” kommando att göra dina ändringar med en kommentar.

För att lösa den borttagna filens sammanfogningskonflikt måste du följa stegen nedan:

1. Öppna Git Bash (Git-kommandorad).
2. Använda sig av CD kommando för att gå till det lokala Git-arkivet som har sammanslagningskonflikten.
3. Använd git-status kommando för att producera listan över filer som påverkas av sammanslagningskonflikten.
4. Öppna textredigeraren som du använder och gå igenom filen som har sammanslagna konflikter.
5. Välj om du vill behålla den borttagna filen. Du kan kontrollera de senaste ändringarna i den borttagna filen i din textredigerare.
6. Använda sig av git add kommando för att lägga till den borttagna filen tillbaka till förvaret. Eller använd gå rm kommando för att ta bort filen från ditt arkiv.
7. Slutligen, använd git commit -m “meddelande” kommando att göra dina ändringar med en kommentar.

F # 17) Hur kommer du att fixa ett brutet åtagande?

Svar: För att fixa ett brutet engagemang eller ändra det senaste engagemanget, är den mest praktiska metoden att använda kommandot “ git commit -amend ' .

Det låter dig kombinera stegvisa förändringar med föregående engagemang som ett alternativ för att skapa ett helt nytt engagemang. Detta ersätter det senaste åtagandet med det ändrade åtagandet.

(bild källa )

Genom det här kommandot kan du också redigera det tidigare meddelandet utan att ändra dess ögonblicksbild.

F # 18) Vad är användningen av git instaweb?

Svar: Det är ett skript genom vilket du direkt kan bläddra i ditt fungerande Git-arkiv i en webbläsare.

Detta skript ställer in gitweb och en webbserver för att bläddra i det lokala förvaret. Den dirigerar automatiskt en webbläsare och kör en webbserver via ett gränssnitt till ditt lokala arkiv.

F # 19) Vad är git is-tree?

Svar: 'Git is-tree' betyder ett trädobjekt som innehåller läget och namnet på alla objekt tillsammans med SHA-1-värdet för klumpen eller trädet.

F # 20) Finns det ett sätt att återställa ett git-engagemang som redan har drivits och offentliggjorts?

Svar: Ja, för att åtgärda eller återställa ett dåligt engagemang finns det två metoder som kan användas baserat på scenariot.

Dom är:

1. Det mycket uppenbara sättet är att göra ett nytt engagemang där du tar bort den dåliga filen eller fixar felen i den. När du är klar kan du trycka på den till ett fjärrförvar.
2. Ett annat tillvägagångssätt är att skapa ett nytt åtagande för att ångra alla ändringar som gjordes i det tidigare dåliga åtagandet. Detta kan göras genom git revert-kommando - “ git återgå '

F # 21) Hur ska du skilja mellan git pull och git hämta?

Svar: Git pull kommandot drar alla nya åtaganden från en viss gren i det centrala förvaret och gör målgrenen i ditt lokala förvar uppdaterad.

Hämta syftar också till samma sak, men dess underliggande funktionalitet är lite annorlunda. När du gör en git-hämtning kommer alla nya åtaganden från en viss gren att dras i ditt centrala arkiv och dessa ändringar lagras i en ny gren i ditt lokala arkiv. Detta kallas en hämtad gren.

Om du vill se dessa ändringar i din målgren måste du utföra en gå samman efter git-hämtning. Målgrenen uppdateras med de senaste ändringarna först efter att den har sammanfogats med den hämtade grenen.

Så, en git pull gör den lokala filialen uppdaterad med sin fjärrversion, medan en git-hämtning inte direkt ändrar din egen lokala filial eller arbetskopia under ref / huvuden. Git-hämtning kan användas för att uppdatera dina fjärrspårningsfilialer under refs / fjärrkontroller //.

Med enkla ord, git pull är lika med git-hämtning följt av en git-sammanslagning .

F # 22) Vad är användningen av Staging-område eller indexering i Git?

Svar: Ur Gits perspektiv finns det tre områden där filändringarna kan sparas, dvs. arbetskatalog, mellanstationer och förvar.

Först gör du ändringar i projektets arbetskatalog som lagras på ditt dators filsystem. Alla ändringar förblir här tills du lägger till dem i ett mellanliggande område som kallas staging area.

Du kan iscensätta ändringarna genom att utföra git add. kommando. Det här iscensättningsområdet ger dig en förhandsgranskning av ditt nästa engagemang och låter dig i princip finjustera dina åtaganden. Du kan lägga till eller ta bort ändringar i iscensättningsområdet tills du är nöjd med den version du ska begå.

När du har verifierat dina ändringar och loggat av scenen ändrad, kan du äntligen begå ändringarna. När de begås går de till det lokala förvaret, dvs. till katalogen .git / objects.

Om du använder Git GUI, kommer du att se alternativet att göra dina ändringar. I nedanstående skärmdump är filen sample.txt under instegade ändringsområde vilket innebär att den finns i din arbetskatalog.

Du kan välja en fil och klicka på ”scenen har ändrats”, sedan flyttas den i iscensättningsområdet. Till exempel , filen hello.txt är närvarande i scenförändrat (kommer att begå) område. Du kan verifiera dina ändringar och sedan göra en avloggning följt av ett åtagande.

Staging kallas också för indexering eftersom git underhåller en indexfil för att hålla reda på dina filändringar över dessa tre områden. De filer som är iscensatta finns för närvarande i ditt index.

När du lägger till ändringar i iscensättningsområdet uppdateras informationen i indexet. När du gör ett engagemang är det faktiskt vad som finns i indexet som blir förpliktat, och inte vad som finns i arbetskatalogen. Du kan använda git-status kommandot för att se vad som finns i indexet.

F # 23) Vad är Git Stash?

Svar: GIT stash fångar det aktuella läget för arbetskatalogen och indexet och håller det på stacken för framtida användning. Den återställer de icke-åtagna ändringarna (både iscensatta och icke-iscensatta) från din arbetskatalog och ger dig ett rent fungerande träd.

Du kan arbeta med något annat nu, och när du kommer tillbaka kan du använda dessa ändringar igen. Så om du vill byta från ett sammanhang till ett annat utan att förlora dina nuvarande ändringar kan du använda stashing.

Det är användbart i snabb kontextbyte, där du befinner dig mitt i en kodändring som du inte vill göra eller ångra just nu och du har något annat att arbeta med. Kommandot att använda är git stash.

F # 24) Vad är Git Stash-droppen?

Svar: När du inte längre behöver en specifik stash kan du ta bort den genom att köra git stash drop-kommando . Om du vill ta bort alla stash på en gång från förvaret kan du köra git stash clear kommando .

F # 25) Vad gäller Git stash? Hur skiljer det sig från Git stash pop?

Svar: Båda kommandona används för att återanvända dina stashade ändringar och börja arbeta från där du hade kvar.

I git stash gäller kommandot, ändringarna kommer att tillämpas på nytt på din arbetskopia och kommer också att förvaras i stash. Detta kommando kan användas när du vill tillämpa samma stashade ändringar på flera grenar.

I git stash pop kommandot tas ändringarna bort från stash och appliceras på nytt på arbetskopian.

F # 26) Vad är användningen av git clone command?

Svar: De git klon kommandot skapar en kopia av det befintliga centrala Git-arkivet till din lokala maskin.

F # 27) När används git config-kommandot?

Svar: De git config kommandot används för att ställa in konfigurationsalternativ för din Git-installation.

Till exempel, efter att du laddat ner Git måste du använda nedanstående konfigurationskommandon för att ställa in användarnamn och begå e-postadress i Git respektive:

$ git config –global user.name “”

$ git config –global user.email “”

Så, främst saker som förvarets beteende, användarinformation och inställningar kan ställas in med hjälp av detta kommando.

F # 28) Hur kommer du att identifiera om filialen redan är sammanslagen till master?

Svar:

Genom att utföra kommandona nedan kan du lära känna grenens sammanslagningsstatus:

1. git branch –merged master: Detta visar alla grenar som har döpts om till master.
2. git gren –smält: Detta kommer att lista ut alla grenar som har slagits samman i HEAD.
3. git-gren - ingen sammanslagning: Detta kommer att lista ut alla filialer som ännu inte är sammanslagna.

Som standard berättar detta kommando sammanfogningsstatus endast för lokala filialer. Om du vill veta om både sammanslagningsstatus för lokal och fjärrkontroll kan du använda -till flagga. Om du bara vill söka efter avlägsna grenar kan du använda -r flagga.

F # 29) Vad är krokar i Git?

Svar: Git hooks är vissa skript som Git kör före eller efter en händelse som begå, push, uppdatera eller ta emot. Du hittar mappen 'hooks' i .git-katalogen i ditt lokala arkiv. Du hittar inbyggda skript här pre-commit, post-commit, pre-push, post push.

Dessa skript körs lokalt före eller efter inträffandet av en händelse. Du kan också ändra dessa skript efter dina behov och Git kommer att köra skriptet när just den här händelsen inträffar.

F # 30) Vad är användningen av gitgaffel? Hur skiljer sig gafflar från kloning?

Svar: Att dela ett projekt innebär att skapa en fjärrkopia av serversidan av det ursprungliga arkivet. Du kan byta namn på denna kopia och börja göra ett nytt projekt kring detta utan att påverka det ursprungliga projektet. Gaffeln är inte kärnkonceptet för Git.

Gaffelfunktionen används av Git-arbetsflödet och den här idén finns längre för gratis programvara med öppen källkod som GitHub. När du väl har gafflat projektet kommer du i allmänhet sällan att bidra till föräldraprojektet igen.

sammanfoga sortera pseudokod c ++

Till exempel, OpenBSD är ett Unix-liknande open source-operativsystem som utvecklades av Forking NetBSD som är ett annat Unix-liknande open source-operativsystem.

I gaffeln finns det dock en direkt koppling mellan din gaffelkopia och originalförvaret. När som helst kan du bidra tillbaka till det ursprungliga projektet genom att använda pull-förfrågningar.

I den gafflade kopian kopieras alla huvuddata som koder och filer från originalförvaret, men filialer, dragförfrågningar och andra funktioner kopieras inte. Forking är ett perfekt sätt för öppen källkodssamarbete.

Kloning är i grunden ett Git-koncept. En klon är en lokal kopia av valfri fjärrförvar. När vi klonar ett förvar kopieras hela källförvaret tillsammans med dess historia och filialer till vår lokala maskin.

Till skillnad från gaffel finns det ingen direkt koppling mellan det klonade förvaret och det ursprungliga fjärrförvaret. Om du vill göra pull-förfrågningar och fortsätta tillbaka till det ursprungliga projektet, bör du få dig själv som en medarbetare i originalförvaret.

Kloning är också ett utmärkt sätt att skapa en säkerhetskopia av originalförvaret, eftersom den klonade kopian också har all engagemangshistorik.

F # 31) Hur får du reda på vad alla filer har ändrats i ett visst Git-engagemang?

Svar: Genom att använda hash-värdet för det specifika engagemanget kan du utföra kommandot nedan för att få en lista över filer som har ändrats i ett visst engagemang:

git diff-tree -r {hash}

Detta listar alla filer som har modifierats och även de filer som har lagts till. Flaggan -r används för att lista enskilda filer tillsammans med deras sökväg istället för att bara kollapsa dem i deras rotkatalognamn.

Du kan också använda kommandot nedan:

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

–No-commit-id kommer att omskola kommandot hashnummer för att komma i utdata. Medan -name utesluter filvägarna och bara ger filnamnen i utdata.

F # 32) Vad är skillnaden mellan git checkout (grennamn) och git checkout -b (grennamn)?

Svar: Kommandot git checkout (filialnamn) byter från en gren till en annan.

Kommandot git checkout -b (filialnamn) kommer att skapa en ny filial och även byta till den.

F # 33) Vad är SubGit?

Svar: SubGit är ett verktyg som används för SVN till Git Migration. Den är utvecklad av ett företag som heter TMate. Det konverterar SVN-förvar till Git och låter dig göra arbete på båda systemen samtidigt. Den synkroniserar automatiskt SVN med Git.

(bild källa )

Du kan skapa en SVN || Git-spegel med det här verktyget. SubGit ska installeras på din Git-server. Det kommer att upptäcka alla inställningar i ditt fjärranslutna SVN-arkiv, inklusive SVN-versioner, filialer och taggar, och konverterar dem till Git-åtaganden.

Det bevarar också historiken inklusive spårning av sammanslagningsdata.

F # 34) Kan du återställa en borttagen gren i Git?

Svar: Jo det kan du. För att återställa en borttagen gren bör du känna till SHA på toppen av ditt huvud. SHA eller hash är ett unikt ID som Git skapar vid varje operation.

När du tar bort en filial visas SHA på terminalen:

Borttagen gren (var)

Du kan använda kommandot nedan för att återställa den raderade grenen:

git kassan -b

Om du inte känner till SHA för åtagandet på spetsen av din filial kan du först använda gå igen kommando för att känna till SHA-värdet och använd sedan ovanstående kassakommando för att återställa din filial.

F # 35) Vad är det? git diff kommando? Hur skiljer det sig från git status?

Svar: Git diff är ett kommando med flera användningsområden som kan köras för att visa skillnaderna mellan två godtyckliga åtaganden, ändringar mellan arbetsträdet och ett engagemang, ändringar mellan arbetsträdet och ett index, ändringar mellan två filer, ändringar mellan indexet och ett träd etc.

De git-status kommandot används för att inspektera ett arkiv. Det visar tillståndet för arbetskatalogen och iscenesättningsområdet. Den listar de filer som har iscensatts, som inte har iscensatts och de filer som inte har spårats.

F # 36) Vad innehåller ett Commit-objekt?

Svar: Engagemangsobjektet innehåller toppnivå-trädets hash, överordnad begår hash (om sådan finns), information om författare och uppdragare, datum för engagemang och meddelande.

Du kan se detta genom git-logg kommando.

Exempel:

(bild källa )

F # 37) Vad är git cherry pick? Vilka är de scenarier där git cherry pick kan användas?

Svar: Git körsbärsplockning är ett kraftfullt kommando för att tillämpa ändringarna som införts av en eller flera befintliga åtaganden. Det låter dig välja ett engagemang från en gren och tillämpa det på en annan.

git cherry-pick commitSha är kommandot som används för körsbärsplockning. commitSha är begåvningsreferensen.

Detta kommando kan användas för att ångra ändringar. Till exempel, om du av misstag har gjort ett åtagande om fel gren, kan du kolla in rätt gren och körplocka engagemanget till var det ska hör hemma.

Den kan också användas i lagsamarbete. Det kan finnas scenarier där samma kod måste delas mellan två komponenter i produkten. I det här fallet, om en utvecklare redan har skrivit den koden, kan den andra körsbärsplocka samma.

Körsbärsplockning är också användbart i felkorrigeringar där en patchplikt kan körsplockas direkt i huvudgrenen för att åtgärda problemet så snart som möjligt.

F # 38) Vad används 'git reset' för? Vad är standardläget för detta kommando?

Svar: Git reset är ett kraftfullt kommando för att ångra lokala förändringar i en Git-repos tillstånd. Detta kommando återställer aktuell HEAD till det angivna steget.

Det återställer både index och arbetskatalog till läget för ditt senaste åtagande. Git reset har tre lägen, dvs mjuk, hård och blandad. Standardläget för drift är blandat.

F # 39) Vad är skillnaden mellan 'HEAD', 'working tree' och 'index'?

Svar: Arbetsträdet eller arbetsytan är den katalog som innehåller de källfiler som du för närvarande arbetar med.

Indexet är iscenesättningsområdet i Git där åtagandena förbereds. Det ligger mellan engagemanget och ditt arbetande träd. Git-index är en stor binär fil som visar alla filer i den aktuella grenen, deras namn, sha1-kontrollsummor och tidsstämplar.

Den här filen finns på /.git/index. HEAD är referensen eller pekaren till det senaste åtagandet i den aktuella kassafilialen.

F # 40) Vad är skillnaden mellan rebase och merge? När ska du återfå och när ska du slå samman?

Svar: Både kommandon för rebase och sammanslagning används för att integrera ändringar från en gren till en annan men på ett annat sätt.

Som framgår av nedanstående två bilder, antar att du har åtaganden (detta är före sammanslagning / rebase). Efter sammanslagningen får du resultatet som en kombination av åtaganden. Det binder samman historien för båda grenarna och skapar en ny ”merge commit” i funktionsgrenen.

Å andra sidan kommer rebase att flytta hela funktionsgrenen för att börja på toppen av mastergrenen.

(bild källa )

Åtaganden kommer att se ut:

Omfördelning rekommenderas inte för offentliga kontor eftersom det skapar inkonsekventa förvar. Omgradering är dock ett bra alternativ för privata filialer / enskilda utvecklare. Det är inte särskilt lämpligt för gren-per-funktion-läge. Men om du har en gren-per-utvecklar-modell, så är det ingen skada att omgradera det.

Rebase är också en destruktiv operation, så ditt utvecklingsteam bör vara tillräckligt skickligt för att tillämpa det korrekt. Annars kan engagerat arbete gå förlorat.

Dessutom är det lättare att återställa en sammanslagning än att återställa en rebase. Så om du vet att det kan finnas möjligheter att återställa krävs, bör du använda sammanslagningen.

Sammanfoga fortsätter historien som den är medan rebase skriver om historien. Således, om du vill se historiken helt som den inträffade bör du använda merge.

F # 41) Vad är syntaxen för omgradering?

Svar: Syntaxen för rebase-kommandot är git rebase (new-commit)

F # 42) Hur tar du bort en fil från Git utan att verkligen ta bort den från ditt lokala filsystem?

Svar: Du kan använda alternativet 'cachat' för detta:

git rm -rf - cached $ FILES

Detta kommando tar bort filerna från ditt arkiv utan att ta bort dem från din disk.

F # 43) Vad är det vanliga förgreningsmönstret i Git?

Svar: Det vanliga förgreningsmönstret är baserat på git-flow. Den har två huvudgrenar, dvs mästare och utveckling.

• Huvudgrenen innehåller produktionskoden. All utvecklingskod slås samman i huvudgrenen någon gång i tiden.
• Utvecklingsgrenen innehåller förproduktionskoden. När funktionerna är färdiga slås de samman med huvudgrenen, vanligtvis via en CI / CD-pipeline.

Denna modell har också några stödgrenar som används under utvecklingscykeln:

• Feature Branches / Topic Branches: De används för att utveckla nya funktioner för kommande utgåvor. Det kan förgrena sig från utvecklingsgrenen och måste slås samman i utvecklingsgrenen. Generellt finns dessa filialer endast i utvecklarförråd och inte i ursprung.
• Snabbkorrigeringsgrenar: De används för oplanerad produktionsrelease när det finns ett behov av att åtgärda kritiska fel direkt i live prod-versionen. De kan förgrena sig från mästare och måste slås samman till utveckla och behärska.
• Släpp grenar: De används för beredning av ny produktionsrelease. Släppgrenen låter dig göra mindre buggfixar och förbereda metadata för släpp. De kan förgrena sig från utveckling och måste slås samman till master och utvecklas.

Slutsats

Vi har gått igenom de viktiga frågorna som generellt ställs under Git-intervjuer i denna handledning.

Detta hjälper dig inte bara att förbereda dig för kommande intervjuer utan kommer också att klargöra dina git-koncept.

Allt det bästa för din intervju!

Rekommenderad läsning

• Intervjufrågor och svar
• Några intressanta programtestintervjufrågor
• Topp 40 C-programmeringsintervjuer och frågor
• Topp 40 populära J2EE intervjufrågor och svar du bör läsa
• ETL Testing Intervju Frågor och svar
• 20+ Vanliga frågor och svar om intervjuintervjuer
• De viktigaste frågorna om Oracle Forms and Reports
• Några knepiga manuella testfrågor och svar