Top 40 GIT-interviewvragen en antwoorden in 2021

top 40 git interview questions

Meest populaire GIT-interviewvragen met antwoorden en voorbeelden:

Deze informatieve tutorial bevat een set van de meest waarschijnlijk gestelde vragen in Git-interviews samen met hun beschrijvende antwoorden. Deze vragen zullen je zeker helpen om je voor te bereiden op en elk Git-interview succesvol te kraken.

Of je nu een beginner bent of een ervaren professional, deze interviewvragen over Git en gedetailleerde antwoorden zullen je zeker helpen je kennis van het onderwerp te verrijken en uit te blinken in je werk en interviews.

Laten we beginnen!!

Meest gestelde GIT-interviewvragen

Hieronder staan ​​enkele van de meest gestelde GIT-interviewvragen ter referentie.

Q # 1) Wat is Git?

Antwoord: Git is een tool voor gedistribueerd versiebeheer. Het is compatibel met gedistribueerde niet-lineaire workflows omdat het gegevenszekerheid biedt voor het bouwen van software van goede kwaliteit.

Git is gratis en open-source. Het kan voor bijna elk soort project worden gebruikt, of het nu klein of groot is. Git staat bekend om zijn grote snelheid en efficiëntie. Git-opslagplaatsen zijn erg gemakkelijk te vinden en te openen. Vanwege zijn bepaalde eigenschappen is Git zeer flexibel, veilig en compatibel met uw systeem.

V # 2) Wat is een gedistribueerd versiebeheersysteem?

Antwoord: Een gedistribueerde VCS is een systeem dat niet afhankelijk is van een centrale server om een ​​projectbestand en al zijn versies te bewaren. In gedistribueerde VCS krijgt elke medewerker of ontwikkelaar een lokale kopie van de hoofdrepository en dit wordt een kloon genoemd.

(beeld bron ​

Zoals je in het bovenstaande diagram kunt zien, onderhoudt elke medewerker een lokale repository op zijn lokale computers. Ze kunnen de lokale repositories probleemloos vastleggen en bijwerken.

Met behulp van een pull-operatie kan een ontwikkelaar zijn lokale repository bijwerken met de laatste wijzigingen van de centrale server. Met behulp van de push-operatie kunnen ze hun wijzigingen vanuit de lokale repository naar de centrale server sturen.

V # 3) Wie heeft Git gemaakt?

Antwoord: Git is gemaakt door Linus Torvalds in 2005 op weg naar de ontwikkeling van Linux Kernel.

Q # 4) Welke taal wordt gebruikt in Git?

Antwoord: C is de onderliggende programmeertaal waarin Git is geschreven. C-taal maakt Git snel door runtime-overheadkosten te omzeilen die zijn gekoppeld aan andere programmeertalen op hoog niveau.

Q # 5) Wat zijn de voordelen / belangrijkste kenmerken van Git?

Antwoord: Hieronder staan ​​de verschillende f eatures van Git.

(i) Gratis en open source:

Git wordt uitgegeven onder de open source-licentie van GPL (General Public License). Je hoeft niets te betalen om Git te gebruiken.

Het is helemaal gratis. Omdat het open-source is, kunt u de broncode aanpassen aan uw behoeften.

(ii) Snelheid:

Omdat u geen verbinding hoeft te maken met een netwerk om alle acties uit te voeren, voert het alle taken snel uit. Het verkrijgen van versiegeschiedenis uit een lokaal opgeslagen opslagplaats kan honderd keer sneller zijn dan het verkrijgen van de externe server.

Git is geschreven in C, wat de onderliggende programmeertaal is die runtime-overheadkosten die verband houden met andere talen op hoog niveau omzeilt.

(iii) schaalbaar:

Git is zeer schaalbaar. Dus als het aantal medewerkers de komende tijd toeneemt, dan kan Git deze verandering gemakkelijk opvangen.

Ondanks het feit dat Git een volledige repository vertegenwoordigt, zijn de gegevens die aan de kant van de klant worden bewaard erg klein, aangezien Git de volledige enorme gegevens comprimeert door middel van een verliesvrije compressietechniek.

(iv) Betrouwbaar:

Omdat elke medewerker zijn eigen lokale repository heeft, kunnen in geval van een systeemcrash de verloren gegevens worden gerecupereerd uit een van de lokale repositories. U heeft altijd een back-up van al uw bestanden.

(v) Veilig:

Git gebruikt de SHA1 (Secure Hash Function) om objecten in zijn repository een naam te geven en te identificeren. Elk artefact en elke vastlegging worden gecontroleerd bij elkaar opgeteld en tijdens het afrekenen hersteld via de controlesom.

De Git-geschiedenis wordt opgeslagen op een manier waarop de ID van een specifieke versie (een commit in termen van Git) afhankelijk is van de totale ontwikkelingsgeschiedenis die loopt tot aan die commit. Zodra een bestandsversie naar Git is gepusht, is er geen manier om deze te wijzigen zonder opgemerkt te worden.

(vi) Economisch:

In het geval van een gecentraliseerd versiebeheersysteem moet de centrale server sterk genoeg zijn om verzoeken van het hele team bij te wonen. Dit is geen probleem voor kleinere teams, maar naarmate het team groter wordt, kunnen de hardwarebeperkingen van de server een belemmering vormen voor de prestaties.

In het geval van gedistribueerde versiebeheersystemen zoals Git, hebben de teamleden geen interactie met de server nodig, behalve wanneer ze wijzigingen moeten pushen of ophalen. Al het zware werk vindt plaats aan de clientzijde, dus de serverhardware kan zeker vrij eenvoudig worden gehouden.

(vii) Ondersteunt niet-lineaire ontwikkeling:

Git biedt snelle branching & merging en bevat specifieke tools voor het visualiseren en doorlopen van een niet-lineaire ontwikkelingsgeschiedenis. Een basisbegrip in Git is dat een wijziging vaker zal worden samengevoegd dan geschreven, aangezien deze naar verschillende recensenten wordt verzonden.

Git Branches zijn extreem licht van gewicht. Een branch in Git verwijst alleen naar een enkele commit. Met behulp van parent commits kan de complete branch-structuur worden aangemaakt.

(viii) Gemakkelijk vertakken:

Filiaalbeheer via Git is heel eenvoudig en gemakkelijk. Het vereist slechts een paar jiffies om branches te maken, verwijderen en samen te voegen. Feature branches geven een geïsoleerde omgeving aan elke wijziging in uw codebase.

Wanneer een ontwikkelaar ergens aan moet beginnen werken, ongeacht de omvang van het werk, maken ze een nieuwe branch aan. Dit zorgt ervoor dat de master branch constant een code van productiekwaliteit heeft.

(ix) Gedistribueerde ontwikkeling:

Git biedt elke ontwikkelaar een lokale kopie van de hele ontwikkelingsgeschiedenis, plus de wijzigingen worden gekloond van de ene opslagplaats naar de andere. Deze wijzigingen worden geïntroduceerd als toegevoegde ontwikkelingstakken en kunnen op dezelfde manier worden samengevoegd als een lokaal ontwikkelde tak.

(x) Compatibiliteit met huidige systemen of protocol:

Repositories kunnen worden gepubliceerd via HTTP, FTP of een Git-protocol bovenop een gewone socket of ssh.

V # 6) Hoe creëer je een repository in Git?

Antwoord: Om een ​​repository aan te maken, moet je een directory voor het project aanmaken als deze nog niet bestaat, en dan simpelweg het commando ' git init ​Door deze opdracht uit te voeren, wordt een .git-directory gemaakt in de projectdirectory, d.w.z. nu is je projectdirectory veranderd in een Git-repository.

V # 7) Wat is een .git-directory?

Antwoord: Op het moment dat u een repository aanmaakt, vindt u daarin een .git-directory. Deze .git-directory bevat alle metadata van de repository en houdt een track bij van alle wijzigingen die zijn aangebracht aan de bestanden in je repository, door een vastleggeschiedenis bij te houden.

Alle informatie met betrekking tot commits, hooks, refs, objectdatabases, remote repository-adressen, etc. worden in deze map bewaard. Dit is het meest cruciale deel van Git. Wanneer je een Git-repository op je lokale computer kloont, is dit .git de directory die daadwerkelijk wordt gekopieerd.

V # 8) Wat gebeurt er als de .git-directory wordt verwijderd?

Antwoord: Als de .git / directory wordt verwijderd, verliest u de geschiedenis van uw project uit het oog. De repository staat niet langer onder versiebeheer.

Q # 9) Welk commando wordt gebruikt voor het schrijven van een Commit Message in Git?

Antwoord: Het commando dat wordt gebruikt om een ​​bericht door te geven aan een git commit is git commit -m “commit bericht”. De vlag m wordt gebruikt om een ​​vastleggingsbericht door te geven.

V # 10) Wat is de kale Git-repository? Hoe verschilt het van een standaard / niet-kale Git-repository?

Antwoord: Repositories die zijn gemaakt via git init commando zijn de standaard / niet-kale Git-repositories.

In de map op het hoogste niveau van een dergelijke repository vindt u twee dingen:

1. Een .git-submap met alle metadata en het bijhouden van de geschiedenis van uw repo.
2. Een werkende boom.

De repositories die zijn gemaakt met git init -bare commando staan ​​bekend als bare Git-repositories. Ze worden voornamelijk gebruikt om te delen. Ze bevatten geen werkende boom. Ze bewaren de git-revisiegeschiedenis van je repository in de root-map in plaats van dat deze in de .git-submap staat.

Het bevat alleen kale repository-gegevens. Dit is hoe een kale Git-repository verschilt van een standaard Git-repository. Ook heeft een kale repository geen standaard remote oorsprong repository aangezien het dient als een oorspronkelijke repository voor meerdere externe gebruikers.

Omdat een kale repository geen werkruimte bevat, kan het git push en git pull commando's werken niet op een kale opslagplaats. U hoeft geen wijzigingen door te voeren in een kale opslagplaats.

V # 11) Noem enkele Git Repository Hosting Services.

Antwoord:

• Github
• Pikacode
• Gitlab
• Microsoft VSTS
• BitBucket
• GitEnterprise
• BronForge
• Lanceerplatform
• Noodgedwongen
• Bonenstaak
• Het lijkt op

V # 12) Noem enkele basisbewerkingen in Git.

Antwoord: Enkele basisbewerkingen in Git zijn onder meer:

• Initialiseer
• Toevoegen
• Commit
• Duwen
• Trekken

V # 13) Noem enkele geavanceerde bewerkingen in Git.

Antwoord: Enkele geavanceerde bewerkingen in Git zijn:

• Vertakking
• Samenvoegen
• Rebasen

Q # 14) Hoe ga je onderscheid maken tussen Git en SVN?

Antwoord: Git is een gedistribueerd versiebeheer, terwijl SVN gecentraliseerd is. Dit leidt tot veel verschillen tussen de twee in termen van hun kenmerken en functionaliteiten.

V # 15) Hoe ga je onderscheid maken tussen Git en GitHub?

Antwoord: Git is een versiebeheersysteem van hoge kwaliteit. Het wordt in de natuur verspreid en wordt gebruikt om veranderingen in de broncode bij te houden tijdens de ontwikkeling van software. Het heeft een uniek vertakkingsmodel dat helpt bij het synchroniseren van werk tussen ontwikkelaars en het bijhouden van wijzigingen in alle bestanden.

De primaire doelen van Git zijn snelheid, data-integriteit en ondersteuning bieden aan gedistribueerde, niet-lineaire workflows. Git wordt geïnstalleerd en onderhouden op de lokale machine, in plaats van in de cloud.

GitHub is een cloudgebaseerde Git-repository-hostingservice die teams samenbrengt. Het geeft je een webgebaseerde GUI en biedt toegangscontrole en veel samenwerkingsfuncties, fundamentele taakbeheertools voor elk project.

GitHub is ook een open-source, d.w.z. code wordt op een gecentraliseerde server bewaard en is voor iedereen toegankelijk.

V # 16) Wat is een conflict in Git en hoe los je dit op?

Antwoord: Git heeft een automatische merge-functie die de merge-commits zelf afhandelt, op voorwaarde dat de codewijzigingen op verschillende regels en in verschillende bestanden hebben plaatsgevonden.

Maar in het geval dat er wordt gestreden om commits waar er veranderingen zijn in dezelfde regels code van een bestand of een bestand is verwijderd in de ene branch maar bestaat en gewijzigd is in een andere, is Git niet in staat om automatisch verschillen op te lossen en veroorzaakt dus samenvoegconflicten.

In dergelijke gevallen heeft u uw hulp nodig om te beslissen welke code u wilt opnemen en welke code u bij de definitieve samenvoeging moet verwijderen.

Een samenvoegconflict kan optreden tijdens het samenvoegen van een branch, het rebasen van een branch of het cherry-picking van een commit. Zodra een conflict is gedetecteerd, markeert Git het conflictgebied en vraagt ​​je om het op te lossen. Zodra het conflict is opgelost, kunt u doorgaan met het samenvoegen.

Volg de onderstaande stappen om een ​​concurrerend samenvoegconflict voor lijnwijzigingen op te lossen:

1. Open Git Bash (Git-opdrachtregel).
2. Gebruik CD commando om naar de lokale Git-repository te gaan die het samenvoegconflict heeft.
3. Gebruik de git status opdracht om de lijst met bestanden te produceren die zijn getroffen door het samenvoegconflict.
4. Open de teksteditor die u gebruikt en ga naar het bestand met samenvoegconflicten.
5. Om het begin van het samenvoegconflict in uw bestand te zien, zoekt u in het document naar de conflictmarkering<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> TAKNAAM.
6. Kies in het geval dat u alleen de wijzigingen van uw branch wilt behouden, gewoon de wijzigingen van de andere branch wilt behouden, of breng een nieuwe wijziging aan, mogelijk inclusief wijzigingen van de twee branches. Wis de conflictmarkeringen<<<<<<>>>>>> en breng de wijzigingen aan die je nodig hebt bij de uiteindelijke samenvoeging.
7. Gebruik git voegt toe. opdracht om uw wijzigingen toe te voegen of te stagen.
8. Gebruik ten slotte de git commit -m 'bericht' commando om uw wijzigingen vast te leggen met een opmerking.

Om het verwijderde conflict met het samenvoegen van bestanden op te lossen, moet u de onderstaande stappen volgen:

1. Open Git Bash (Git-opdrachtregel).
2. Gebruik CD commando om naar de lokale Git-repository te gaan met het samenvoegconflict.
3. Gebruik de git status opdracht om de lijst met bestanden te produceren die zijn getroffen door het samenvoegconflict.
4. Open de teksteditor die u gebruikt en ga naar het bestand met samenvoegconflicten.
5. Kies of u het verwijderde bestand wilt behouden. U kunt de laatste wijzigingen in het verwijderde bestand in uw teksteditor bekijken.
6. Gebruik git add commando om het verwijderde bestand weer toe te voegen aan de repository. Of gebruik ga rm opdracht om het bestand uit uw repository te verwijderen.
7. Gebruik ten slotte de git commit -m 'bericht' commando om uw wijzigingen vast te leggen met een opmerking.

V # 17) Hoe ga je een Broken Commit oplossen?

Antwoord: Om een ​​verbroken commit te repareren of om de laatste commit te wijzigen, is de handigste methode om het commando “ git commit -amend ' ​

Het stelt je in staat om gefaseerde wijzigingen te combineren met de vorige commit als alternatief voor het aanmaken van een geheel nieuwe commit. Dit vervangt de meest recente commit door de gewijzigde commit.

(beeld bron ​

beste mp3-downloader voor Windows 10

Met deze opdracht kun je ook het vorige vastleggingsbericht bewerken zonder de momentopname ervan te wijzigen.

Q # 18) Wat is het gebruik van git instaweb?

Antwoord: Het is een script waarmee u direct door uw werkende Git-repository in een webbrowser kunt bladeren.

Dit script stelt gitweb en een webserver in om door de lokale repository te bladeren. Het stuurt automatisch een webbrowser en voert een webserver uit via een interface naar uw lokale repository.

Q # 19) Wat is git is-tree?

Antwoord: ‘Git is-tree’ geeft een boomobject aan dat de modus en de naam van alle items omvat, samen met de SHA-1-waarde van de blob of de boom.

Q # 20) Is er een manier om een ​​git commit terug te draaien die al gepusht en openbaar gemaakt is?

Antwoord: Ja, om een ​​slechte commit te herstellen of ongedaan te maken, zijn er twee benaderingen die kunnen worden gebruikt op basis van het scenario.

Zij zijn:

1. De zeer voor de hand liggende manier is om een ​​nieuwe commit te maken waarbij je het slechte bestand verwijdert of de fouten erin herstelt. Als u klaar bent, kunt u het naar een externe opslagplaats pushen.
2. Een andere benadering is om een ​​nieuwe commit te maken om alle wijzigingen ongedaan te maken die zijn gemaakt in de vorige slechte commit. Dit kan gedaan worden met het git revert commando - “ git revert '

Q # 21) Hoe ga je onderscheid maken tussen git pull en git fetch?

Antwoord: Git pull commando haalt alle nieuwe commits uit een specifieke branch in de centrale repository en maakt de doel branch in je lokale repository up-to-date.

Git ophalen richt zich ook op hetzelfde, maar de onderliggende functionaliteit is een beetje anders. Als je een git fetch doet, zullen alle nieuwe commits van een specifieke branch in je centrale repository worden opgehaald en deze wijzigingen zullen in een nieuwe branch in je lokale repository worden opgeslagen. Dit wordt een opgehaalde tak genoemd.

Als u deze wijzigingen in uw doeltak wilt zien, moet u een ga samenvoegen na git fetch. De doeltak wordt pas bijgewerkt met de laatste wijzigingen nadat deze is samengevoegd met de opgehaalde vertakking.

Dus een git pull brengt de lokale branch up-to-date met zijn remote versie, terwijl een git fetch niet direct je eigen lokale branch of werkkopie verandert onder refs / heads. Git fetch kan worden gebruikt om uw remote-tracking branches onder bij te werken refs / afstandsbedieningen //.

In eenvoudige bewoordingen, git pull is gelijk aan git fetch gevolgd door een git merge ​

V # 22) Wat is het gebruik van Staging-gebied of Indexing in Git?

Antwoord: Vanuit het perspectief van Git zijn er drie gebieden waar de bestandswijzigingen kunnen worden bewaard, namelijk werkdirectory, staging-gebied en repository.

Eerst brengt u wijzigingen aan in de werkmap van uw project die is opgeslagen op het bestandssysteem van uw computer. Alle wijzigingen blijven hier totdat u ze toevoegt aan een tussengebied genaamd staging-gebied.

U kunt de wijzigingen faseren door uit te voeren git add. opdracht. Dit staging-gebied geeft je een voorbeeld van je volgende commit en laat je in feite je commits verfijnen. U kunt wijzigingen in het staging-gebied toevoegen of verwijderen totdat u tevreden bent met de versie die u gaat vastleggen.

Zodra u uw wijzigingen heeft geverifieerd en de gewijzigde fase heeft afgemeld, kunt u de wijzigingen eindelijk doorvoeren. Na vastlegging gaan ze naar de lokale repository, d.w.z. naar de .git / objects-directory.

Als je Git GUI gebruikt, zul je de optie zien om je wijzigingen te stagen. In de onderstaande schermafbeelding bevindt het bestand sample.txt zich onder het gebied unstaged changes, wat betekent dat het in uw werkmap staat.

U kunt een bestand selecteren en op ‘stage gewijzigd’ klikken, waarna het wordt verplaatst in het verzamelgebied. Bijvoorbeeld , het bestand hello.txt is aanwezig in het gebied veranderd fase (zal vastleggen). U kunt uw wijzigingen verifiëren en vervolgens een afmelding doen, gevolgd door een vastlegging.

Staging wordt ook wel indexeren genoemd omdat git een indexbestand bijhoudt om je bestandswijzigingen in deze drie gebieden bij te houden. De bestanden die worden geënsceneerd, staan ​​momenteel in uw index.

Wanneer u wijzigingen toevoegt aan het verzamelgebied, wordt de informatie in de index bijgewerkt. Als je een commit doet, is het in feite wat er in de index staat dat wordt vastgelegd, en niet wat er in de werkdirectory staat. U kunt de git status commando om te zien wat er in de index staat.

V # 23) Wat is Git Stash?

Antwoord: GIT stash legt de huidige status van de werkdirectory en index vast en bewaart deze op de stapel voor toekomstig gebruik. Het zet de niet-gecommitteerde wijzigingen (zowel staged als unstaged) uit je werkdirectory terug en geeft je een schone werkende boom.

U kunt nu aan iets anders werken en wanneer u terugkomt, kunt u deze wijzigingen opnieuw toepassen. Dus als u van de ene context naar de andere wilt overschakelen zonder uw huidige wijzigingen te verliezen, kunt u stashing gebruiken.

Het is handig bij het snel wisselen van context, waarbij u zich halverwege een codewijziging bevindt die u niet wilt vastleggen of ongedaan wilt maken, en u heeft iets anders om aan te werken. Het te gebruiken commando is git stash.

Q # 24) Wat is de Git Stash-drop?

Antwoord: Als je een specifieke stash niet langer nodig hebt, kun je deze verwijderen door git stash drop-opdracht ​Als je alle stashes in één keer uit de repository wilt verwijderen, kun je uitvoeren git stash clear commando ​

Q # 25) Wat is Git stash van toepassing? Waarin verschilt het van Git stash pop?

Antwoord: Beide opdrachten worden gebruikt om uw opgeslagen wijzigingen opnieuw toe te passen en te beginnen met werken waar u was gebleven.

In git stash toepassen commando, zullen de wijzigingen opnieuw worden toegepast op je werkkopie en ook in de stash bewaard worden. Dit commando kan worden gebruikt als u dezelfde opgeslagen wijzigingen op meerdere branches wilt toepassen.

In git stash pop commando, worden de wijzigingen verwijderd uit de stash en worden ze opnieuw toegepast op de werkkopie.

V # 26) Wat is het gebruik van het git clone-commando?

Antwoord: De git kloon commando maakt een kopie van de bestaande centrale Git-repository naar uw lokale machine.

V # 27) Wanneer wordt het git config-commando gebruikt?

Antwoord: De git config commando wordt gebruikt om configuratie-opties in te stellen voor je Git-installatie.

Bijvoorbeeld, nadat je Git hebt gedownload, moet je de onderstaande configuratieopdrachten gebruiken om respectievelijk de gebruikersnaam en het e-mailadres in Git in te stellen:

$ git config –global user.name “”

$ git config –global user.email “”

Dus voornamelijk zaken als het gedrag van de repository, gebruikersinformatie en voorkeuren kunnen worden ingesteld met behulp van deze opdracht.

V # 28) Hoe weet je of de branch al is samengevoegd met master?

Antwoord:

Door de onderstaande commando's uit te voeren, kunt u de status van het samenvoegen van vertakkingen te weten komen:

1. git branch - samengevoegde master: Hiermee worden alle branches weergegeven die zijn hernoemd naar master.
2. git branch - samengevoegd: Hiermee worden alle branches weergegeven die in HEAD zijn samengevoegd.
3. git branch –no-merged: Hiermee worden alle branches weergegeven die nog niet zijn samengevoegd.

Standaard vertelt dit commando alleen de samenvoegstatus van lokale branches. Als je meer wilt weten over de merge-status van zowel lokale als externe filialen, dan kun je -naar vlag. Als u alleen naar externe branches wilt controleren, kunt u -r vlag.

V # 29) Wat zijn hooks in Git?

Antwoord: Git-hooks zijn bepaalde scripts die Git voor of na een gebeurtenis uitvoert, zoals vastleggen, pushen, bijwerken of ontvangen. Je vindt de map ‘hooks’ in de .git-directory in je lokale repository. Je vindt de ingebouwde scripts hier pre-commit, post-commit, pre-push, post push.

Deze scripts worden lokaal uitgevoerd voor of na het optreden van een gebeurtenis. Je kunt deze scripts ook aanpassen aan je behoeften en Git zal het script uitvoeren wanneer die specifieke gebeurtenis plaatsvindt.

V # 30) Wat is het gebruik van git fork? Waarin verschilt forken van klonen?

Antwoord: Een project splitsen betekent dat u een externe server-side kopie van de originele repository maakt. U kunt deze kopie een andere naam geven, en hieromheen een nieuw project beginnen te doen zonder het originele project te beïnvloeden. De vork is niet het kernconcept van Git.

De vorkbewerking wordt gebruikt door de Git-workflow en dit idee bestaat al langer voor gratis en open-source software zoals GitHub. Over het algemeen zul je, als je eenmaal het project hebt geforked, zelden meer bijdragen aan het bovenliggende project.

Bijvoorbeeld, OpenBSD is een Unix-achtig open-source besturingssysteem dat is ontwikkeld door NetBSD te forking, een ander Unix-achtig open-source besturingssysteem.

In de fork bestaat er echter een directe verbinding tussen uw geforkte kopie en de originele repository. U kunt op elk moment weer bijdragen aan het oorspronkelijke project door de pull-verzoeken te gebruiken.

In de gevorkte kopie worden alle hoofdgegevens zoals codes en bestanden gekopieerd uit de originele repository, maar vertakkingen, pull-verzoeken en andere functies worden niet gekopieerd. Forking is een ideale manier voor open source-samenwerking.

Klonen is in wezen een Git-concept. Een kloon is een lokale kopie van een externe opslagplaats. Wanneer we een repository klonen, wordt de volledige bronrepository samen met zijn geschiedenis en takken gekopieerd naar onze lokale machine.

In tegenstelling tot forking is er geen directe verbinding tussen de gekloonde repository en de originele remote repository. Als je pull-verzoeken wilt doen en terug wilt gaan naar het originele project, dan zou je jezelf als medewerker in de originele repository moeten laten toevoegen.

voeg een element toe aan een array

Klonen is ook een geweldige manier om een ​​back-up te maken van de originele repository, aangezien de gekloonde kopie ook de hele vastleghistorie heeft.

V # 31) Hoe kom je erachter wat alle bestanden zijn veranderd in een bepaalde Git-commit?

Antwoord: Door de hash-waarde van de specifieke commit te gebruiken, kun je het onderstaande commando uitvoeren om de lijst met bestanden op te halen die in een bepaalde commit zijn gewijzigd:

git diff-tree -r {hash}

Dit zal alle bestanden weergeven die zijn gewijzigd, en ook de bestanden die zijn toegevoegd. De vlag -r wordt gebruikt om individuele bestanden samen met hun pad weer te geven in plaats van ze alleen in hun hoofdmap samen te vouwen.

U kunt ook de onderstaande opdracht gebruiken:

git diff-tree –no-commit-id –naam-alleen -r {hash}

–No-commit-id zal de commit-hash-nummers opnieuw trainen zodat ze in de uitvoer komen. Terwijl, -name de bestandspaden uitsluit en alleen de bestandsnamen in de uitvoer geeft.

Q # 32) Wat is het verschil tussen git checkout (branch name) en git checkout -b (branch name)?

Antwoord: Het bevel git checkout (branch naam) zal van de ene branch naar de andere overschakelen.

Het bevel git checkout -b (branch naam) zal een nieuwe branch aanmaken en er ook naar overschakelen.

Q # 33) Wat is SubGit?

Antwoord: SubGit is een tool die wordt gebruikt voor SVN naar Git-migratie. Het is ontwikkeld door een bedrijf genaamd TMate. Het converteert de SVN-repositories naar Git en laat je tegelijkertijd op beide systemen werken. Het synchroniseert de SVN automatisch met Git.

(beeld bron ​

U kunt met deze tool een SVN || Git-spiegel maken. SubGit zou op je Git-server moeten zijn geïnstalleerd. Het zal alle instellingen van je externe SVN-repository detecteren, inclusief SVN-revisies, branches en tags, en ze converteren naar Git-commits.

Het bewaart ook de geschiedenis, inclusief het bijhouden van samenvoeggegevens.

Q # 34) Kun je een verwijderde branch in Git herstellen?

Antwoord: Ja dat kan. Om een ​​verwijderde branch te herstellen, zou je de SHA uit je hoofd moeten kennen. SHA of hash is een unieke ID die Git bij elke operatie aanmaakt.

Wanneer u een branch verwijdert, krijgt u de SHA weergegeven op de terminal:

Verwijderde branch (was)

U kunt de onderstaande opdracht gebruiken om de verwijderde branch te herstellen:

git checkout -b

Als je de SHA voor de commit aan het uiteinde van je branch niet kent, dan kun je eerst de ga reflog commando om de SHA-waarde te kennen en pas dan het bovenstaande checkout commando toe om je branch te herstellen.

Q # 35) Wat is git diff opdracht? Hoe verschilt het van git status?

Antwoord: Git diff is een multi-use commando dat kan worden uitgevoerd om de verschillen te tonen tussen twee willekeurige commits, veranderingen tussen de werkende boom en een commit, veranderingen tussen een werkende boom en een index, veranderingen tussen twee bestanden, veranderingen tussen een index en een boom, etc.

De git status commando wordt gebruikt om een ​​repository te inspecteren. Het toont de status van de werkdirectory en het verzamelgebied. Het geeft een lijst van de bestanden die zijn gestaged, die niet zijn gestaged en de bestanden die niet zijn bijgehouden.

Q # 36) Wat bevat een Commit-object?

Antwoord: Het commit-object bevat de hash van het boomobject op het hoogste niveau, parent commits hash (indien aanwezig), auteur en committer informatie, commit datum en commit bericht.

U kunt dit bekijken via het git log opdracht.

Voorbeeld:

(beeld bron ​

Q # 37) Wat is git cherry-pick? Wat zijn de scenario's waarin git cherry-pick kan worden gebruikt?

Antwoord: Git cherry-pick is een krachtig commando om de wijzigingen toe te passen die door een of meer bestaande commits zijn geïntroduceerd. Het staat je toe om een ​​commit uit de ene branch te kiezen en deze op een andere toe te passen.

git cherry-pick commitSha is het commando dat wordt gebruikt voor cherry-picking. commitSha is de commit-referentie.

Dit commando kan worden gebruikt om wijzigingen ongedaan te maken. Als je bijvoorbeeld per ongeluk een commit hebt gemaakt naar een verkeerde branch, dan kun je de juiste branch uitchecken en de commit uitkiezen waar hij hoort te horen.

Het kan ook worden gebruikt in teamsamenwerking. Er kunnen scenario's zijn waarin dezelfde code moet worden gedeeld tussen twee componenten van het product. In dit geval, als de ene ontwikkelaar die code al heeft geschreven, kan de andere dezelfde code kiezen.

Cherry-picking is ook handig bij bug-hotfixes waar een patch-commit direct in de master branch kan worden geplukt om het probleem zo snel mogelijk op te lossen.

V # 38) Waar wordt ‘git reset’ voor gebruikt? Wat is de standaardmodus van deze opdracht?

Antwoord: Git gereset is een krachtig commando voor het ongedaan maken van lokale wijzigingen in de staat van een Git-opslagplaats. Dit commando reset de huidige HEAD naar het gespecificeerde stadium.

Het reset zowel de index als de werkdirectory naar de staat van je laatste commit. Git reset heeft drie modi, namelijk zacht, hard en gemengd. De standaardmodus is gemengd.

V # 39) Wat is het verschil tussen ‘HEAD’, ‘working tree’ en ‘index’?

Antwoord: De werkboom of werkruimte is de map met de bronbestanden waaraan u momenteel werkt.

De index is het staging-gebied in Git waar de commits worden voorbereid. Het ligt tussen de commit en je werkende boom. Git-index is een groot binair bestand dat alle bestanden in de huidige branch, hun namen, sha1-checksums en tijdstempels, bevat.

Dit bestand is aanwezig op /.git/index. HEAD is de referentie of pointer naar de laatste commit in de huidige checkout branch.

V # 40) Wat is het verschil tussen rebase en merge? Wanneer moet je rebasen en wanneer moet je fuseren?

Antwoord: Zowel rebase- als merge-commando's worden gebruikt om wijzigingen van de ene branch naar de andere te integreren, maar op een andere manier.

Zoals je kunt zien in de onderstaande twee afbeeldingen, stel dat je commits hebt (dit is vóór merge / rebase). Na het samenvoegen krijg je het resultaat als een combinatie van commits. Het bindt de histories van beide branches samen en creëert een nieuwe ‘merge commit’ in de feature branch.

Aan de andere kant zal rebase de hele feature branch verplaatsen om te beginnen bij het uiteinde van de master branch.

(beeld bron ​

Commits zien er als volgt uit:

Rebasen wordt niet aanbevolen voor openbare vertakkingen, aangezien het inconsistente opslagplaatsen creëert. Rebasen is echter een goede optie voor particuliere vestigingen / individuele ontwikkelaars. Het is niet erg geschikt voor branch-per-feature-modus. Maar als je een branch-per-developer-model hebt, dan is rebasen niet schadelijk.

Rebase is ook een destructieve operatie, dus uw ontwikkelingsteam moet bekwaam genoeg zijn om het correct toe te passen. Anders kan toegewijd werk verloren gaan.

Bovendien is het terugdraaien van een samenvoeging gemakkelijker dan het terugdraaien van een rebase. Dus als u weet dat er mogelijkheden voor herstel vereist zijn, moet u de samenvoeging gebruiken.

Samenvoegen zet de geschiedenis voort zoals die is, terwijl rebase de geschiedenis herschrijft. Dus als u de geschiedenis volledig wilt zien zoals deze zich heeft voorgedaan, moet u samenvoegen gebruiken.

V # 41) Wat is de syntaxis voor rebasen?

Antwoord: De syntaxis voor rebase-opdracht is git rebase (nieuwe commit)

V # 42) Hoe ga je een bestand uit Git verwijderen zonder het daadwerkelijk van je lokale bestandssysteem te verwijderen?

Antwoord: U kunt hiervoor de optie ‘in de cache’ gebruiken:

git rm -rf - $ FILES in de cache

Met deze opdracht worden de bestanden uit uw repository verwijderd zonder ze van uw schijf te verwijderen.

Q # 43) Wat is het algemene vertakkingspatroon in Git?

Antwoord: Het algemene vertakkingspatroon is gebaseerd op de git-flow. Het heeft twee hoofdtakken, namelijk master en ontwikkeling.

• De master branch bevat de productiecode. Alle ontwikkelcode wordt op een bepaald moment in de masterbranch samengevoegd.
• De ontwikkelingstak bevat de pre-productiecode. Wanneer de functies zijn voltooid, worden ze samengevoegd met de master-branch, meestal via een CI / CD-pijplijn.

Dit model heeft ook enkele ondersteunende takken die worden gebruikt tijdens de ontwikkelingscyclus:

• Feature Branches / Topic Branches: Ze worden gebruikt om nieuwe functies te ontwikkelen voor aankomende releases. Het kan een aftakking zijn van de ontwikkeltak en moet weer worden samengevoegd met de ontwikkeltak. Over het algemeen bestaan ​​deze branches alleen in ontwikkelaarsrepository's, en niet in origin.
• Hotfix-takken: Ze worden gebruikt voor ongeplande productierelease wanneer het nodig is om een ​​kritieke bug onmiddellijk in de live-productversie op te lossen. Ze kunnen afsplitsen van master en moeten weer worden samengevoegd met ontwikkelen en master.
• Vrijgavetakken: Ze worden gebruikt voor de voorbereiding van een nieuwe productierelease. De releasetak laat je kleine bugfixes doen en metadata voorbereiden voor release. Ze kunnen afsplitsen van ontwikkeling en moeten weer worden samengevoegd tot master en ontwikkelen.

Gevolgtrekking

We hebben de belangrijke vragen doorlopen die over het algemeen worden gesteld tijdens Git-interviews in deze tutorial.

Dit zal je niet alleen helpen om je voor te bereiden op aanstaande interviews, maar zal ook je git-concepten verduidelijken.

Het allerbeste voor uw interview!

Aanbevolen literatuur

• Interview vragen en antwoorden
• Enkele interessante sollicitatievragen voor het testen van software
• Top 40 C-programmeervragen en antwoorden
• Top 40 populaire J2EE interviewvragen en antwoorden die u zou moeten lezen
• Vragen en antwoorden over ETL-tests
• 20+ meest gestelde vragen en antwoorden voor exit-interviews
• Top Oracle Forms and Reports Interviewvragen
• Enkele lastige vragen en antwoorden voor handmatig testen