Top 40 Fragen und Antworten zum GIT-Interview im Jahr 2021

top 40 git interview questions

Die beliebtesten GIT-Interviewfragen mit Antworten und Beispielen:

Dieses informative Tutorial enthält eine Reihe der wahrscheinlichsten Fragen in Git-Interviews sowie deren beschreibende Antworten. Diese Fragen werden Ihnen sicherlich dabei helfen, sich auf ein Git-Interview vorzubereiten und es erfolgreich zu knacken.

Egal, ob Sie ein Anfänger oder ein erfahrener Profi sind, diese Interviewfragen auf Git und detaillierte Antworten werden Ihnen definitiv helfen, Ihr Wissen über das Thema zu erweitern und sich bei Ihrer Arbeit sowie bei Interviews hervorzuheben.

Lass uns anfangen!!

Am häufigsten gestellte Fragen zum GIT-Interview

Nachfolgend finden Sie einige der häufig gestellten Fragen zu GIT-Interviews als Referenz.

F # 1) Was ist Git?

Antworten: Git ist ein Tool zur verteilten Versionskontrolle. Es ist mit verteilten nichtlinearen Workflows kompatibel, da es Datensicherheit für die Erstellung qualitativ hochwertiger Software bietet.

Git ist kostenlos und Open Source. Es kann für fast jede Art von Projekt verwendet werden, sei es klein oder groß. Git ist bekannt für seine hohe Geschwindigkeit und Effizienz. Git-Repositories sind sehr einfach zu finden und zugänglich. Aufgrund seiner bestimmten Funktionen ist Git hochflexibel, sicher und mit Ihrem System kompatibel.

F # 2) Was ist ein verteiltes Versionskontrollsystem?

Antworten: Ein verteiltes VCS ist ein System, das nicht von einem zentralen Server abhängig ist, um eine Projektdatei und alle ihre Versionen zu speichern. In verteiltem VCS erhält jeder Mitarbeiter oder Entwickler eine lokale Kopie des Hauptrepositorys, die als Klon bezeichnet wird.

(Bild Quelle ))

Wie Sie im obigen Diagramm sehen können, verwaltet jeder Mitarbeiter ein lokales Repository auf seinen lokalen Computern. Sie können die lokalen Repositorys ohne Probleme festschreiben und aktualisieren.

Mithilfe einer Pull-Operation kann ein Entwickler sein lokales Repository mit den neuesten Änderungen vom zentralen Server aktualisieren. Mithilfe der Push-Operation können sie ihre Änderungen vom lokalen Repository an den zentralen Server senden.

F # 3) Wer hat Git erstellt?

Antworten: Git wurde 2005 von Linus Torvalds auf dem Weg zur Entwicklung des Linux-Kernels entwickelt.

F # 4) Welche Sprache wird in Git verwendet?

Antworten: C ist die zugrunde liegende Programmiersprache, in der Git geschrieben ist. Die Sprache C macht Git schnell, indem sie Laufzeit-Overheads vermeidet, die mit anderen Programmiersprachen auf hoher Ebene verbunden sind.

F # 5) Was sind die Vorteile / Hauptmerkmale von Git?

Antwort: Nachfolgend sind die verschiedenen f aufgeführt Essen von Git.

(i) Free & Open Source:

Git wird unter der Open Source-Lizenz der GPL (General Public License) ausgestellt. Sie müssen nichts bezahlen, um Git zu benutzen.

Es ist absolut kostenlos. Da es sich um Open Source handelt, können Sie den Quellcode Ihren Anforderungen entsprechend ändern.

(ii) Geschwindigkeit:

Da Sie keine Verbindung zu einem Netzwerk herstellen müssen, um alle Aktionen auszuführen, werden alle Aufgaben schnell ausgeführt. Das Abrufen des Versionsverlaufs von einem lokal gespeicherten Repository kann hundertmal schneller sein als das Abrufen vom Remote-Server.

Git ist in C geschrieben, der zugrunde liegenden Programmiersprache, die Laufzeit-Overheads vermeidet, die mit anderen Hochsprachen verknüpft sind.

(iii) Skalierbar:

Git ist hoch skalierbar. Wenn also die Anzahl der Mitarbeiter in der kommenden Zeit zunimmt, kann Git diese Änderung problemlos berücksichtigen.

Trotz der Tatsache, dass Git ein gesamtes Repository darstellt, sind die auf der Client-Seite gespeicherten Daten sehr klein, da Git die gesamten umfangreichen Daten durch eine verlustfreie Komprimierungstechnik komprimiert.

(iv) Zuverlässig:

Da jeder Mitarbeiter über ein eigenes lokales Repository verfügt, können bei einem Systemabsturz die verlorenen Daten aus jedem der lokalen Repositorys wiederhergestellt werden. Sie haben jederzeit eine Sicherungskopie aller Ihrer Dateien.

(v) Sicher:

Git verwendet die SHA1 (Secure Hash Function), um Objekte in seinem Repository zu benennen und zu identifizieren. Jedes Artefakt und Commit wird beim Auschecken überprüft und über die Prüfsumme wiederhergestellt.

Der Git-Verlauf wird so gespeichert, dass die ID einer bestimmten Version (ein Commit in Bezug auf Git) vom gesamten Entwicklungsverlauf abhängt, der bis zu diesem Commit ausgeführt wird. Sobald eine Dateiversion an Git gesendet wurde, kann sie nicht mehr unbemerkt geändert werden.

(vi) Wirtschaftlich:

Bei einem zentralisierten Versionskontrollsystem muss der zentrale Server stark genug sein, um Anforderungen des gesamten Teams gerecht zu werden. Dies ist für kleinere Teams kein Problem. Wenn das Team jedoch erweitert wird, können die Hardwareeinschränkungen des Servers die Leistung beeinträchtigen.

Bei verteilten Versionskontrollsystemen wie Git benötigen die Teammitglieder keine Interaktion mit dem Server, wenn sie Änderungen pushen oder ziehen müssen. Das ganze schwere Heben erfolgt auf Client-Seite, so dass die Serverhardware mit Sicherheit recht einfach gehalten werden kann.

(vii) Unterstützt nichtlineare Entwicklung:

Git bietet schnelles Verzweigen und Zusammenführen und enthält spezielle Tools zum Vorstellen und Durchlaufen einer nichtlinearen Entwicklungshistorie. Ein Grundgedanke in Git ist, dass eine Änderung häufiger zusammengeführt wird als geschrieben, da sie an verschiedene Prüfer gesendet wird.

Git Branches sind extrem leicht. Ein Zweig in Git bezieht sich nur auf ein einzelnes Commit. Die vollständige Zweigstruktur kann mithilfe von übergeordneten Commits erstellt werden.

(viii) Einfache Verzweigung:

Die Filialverwaltung über Git ist sehr einfach und unkompliziert. Das Erstellen, Löschen und Zusammenführen von Zweigen erfordert nur wenige Augenblicke. Feature-Zweige bieten bei jeder Änderung Ihrer Codebasis eine isolierte Umgebung.

Open Source Rest API Testtools

Wenn ein Entwickler unabhängig von der Größe der Arbeit mit der Arbeit an etwas beginnen muss, erstellt er einen neuen Zweig. Dies stellt sicher, dass die Hauptniederlassung ständig einen Code für die Produktionsqualität enthält.

(ix) Verteilte Entwicklung:

Git stellt jedem Entwickler eine lokale Kopie des gesamten Entwicklungsverlaufs zur Verfügung, und die Änderungen werden von einem solchen Repository in ein anderes geklont. Diese Änderungen werden als hinzugefügte Entwicklungszweige eingeführt und können auf dieselbe Weise wie ein lokal entwickelter Zweig zusammengeführt werden.

(x) Kompatibilität mit den gegenwärtigen Systemen oder Protokollen:

Repositorys können über HTTP, FTP oder ein Git-Protokoll entweder über einen einfachen Socket oder über ssh veröffentlicht werden.

F # 6) Wie erstellt man ein Repository in Git?

Antworten: Um ein Repository zu erstellen, müssen Sie ein Verzeichnis für das Projekt erstellen, falls es noch nicht vorhanden ist, und dann einfach den Befehl „ git init ”. Durch Ausführen dieses Befehls wird ein .git-Verzeichnis innerhalb des Projektverzeichnisses erstellt, d. H. Jetzt hat sich Ihr Projektverzeichnis in ein Git-Repository verwandelt.

F # 7) Was ist ein .git-Verzeichnis?

Antworten: Sobald Sie ein Repository erstellen, finden Sie darin ein .git-Verzeichnis. Dieses .git-Verzeichnis enthält alle Metadaten des Repositorys und verwaltet alle Änderungen, die an den Dateien in Ihrem Repository vorgenommen wurden, indem ein Commit-Verlauf beibehalten wird.

Alle Informationen zu Commits, Hooks, Refs, Objektdatenbanken, Remote-Repository-Adressen usw. werden in diesem Ordner gespeichert. Dies ist der wichtigste Teil von Git. Wenn Sie ein Git-Repository auf Ihrem lokalen Computer klonen, ist diese .git das Verzeichnis, das tatsächlich kopiert wird.

F # 8) Was passiert, wenn das .git-Verzeichnis gelöscht wird?

Antworten: Wenn das Verzeichnis .git / gelöscht wird, verlieren Sie den Überblick über den Verlauf Ihres Projekts. Das Repository steht nicht mehr unter Versionskontrolle.

F # 9) Mit welchem ​​Befehl wird eine Commit-Nachricht in Git geschrieben?

Antworten: Der Befehl zum Weiterleiten einer Nachricht an ein Git-Commit lautet git commit -m 'Commit-Nachricht'. Die Flagge m wird verwendet, um eine Festschreibungsnachricht zu übergeben.

F # 10) Was ist das nackte Git-Repository? Wie unterscheidet es sich von einem Standard / nicht nackten Git-Repository?

Antworten: Repositorys, die durch erstellt werden git init Befehl sind die Standard- / nicht nackten Git-Repositorys.

Im obersten Ordner eines solchen Repositorys finden Sie zwei Dinge:

1. Ein .git-Unterverzeichnis, in dem alle Metadaten und der Verlauf Ihres Repos gespeichert sind.
2. Ein funktionierender Baum.

Die Repositorys, die mit erstellt werden git init –bare Befehle werden als Bare-Git-Repositorys bezeichnet. Sie werden hauptsächlich zum Teilen verwendet. Sie enthalten keinen Arbeitsbaum. Sie speichern den Git-Revisionsverlauf Ihres Repositorys im Stammordner, anstatt ihn im Unterordner .git zu haben.

Es enthält nur nackte Repository-Daten. So unterscheidet sich ein nacktes Git-Repository von einem Standard-Git-Repository. Außerdem verfügt ein nacktes Repository nicht über eine Standardfernbedienung Ursprung Repository, da es als Ursprungs-Repository für mehrere Remote-Benutzer dient.

Da ein nacktes Repository keinen Arbeitsbereich enthält, wird die Git Push und Git Pull Befehle funktionieren nicht über ein nacktes Repo. Sie müssen keine Änderungen an einem Bare Repo vornehmen.

F # 11) Erwähnen Sie einige Git Repository Hosting Services.

Antworten:

• Github
• Pikacode
• Gitlab
• Microsoft VSTS
• Bit Bucket
• GitEnterprise
• SourceForge
• LaunchPad
• Perforce
• Bohnenstange
• Es sieht aus wie

F # 12) Nennen Sie einige grundlegende Operationen in Git.

Antworten: Einige grundlegende Operationen in Git umfassen:

• Initialisieren
• Hinzufügen
• Verpflichten
• drücken
• ziehen

F # 13) Nennen Sie einige erweiterte Operationen in Git.

Antworten: Einige erweiterte Operationen in Git sind:

• Verzweigung
• Zusammenführen
• Wiederherstellen

F # 14) Wie werden Sie zwischen Git und SVN unterscheiden?

Antworten: Git ist eine verteilte Versionskontrolle, während SVN zentralisiert ist. Dies führt zu vielen Unterschieden zwischen den beiden hinsichtlich ihrer Merkmale und Funktionen.

F # 15) Wie werden Sie zwischen Git und GitHub unterscheiden?

Antworten: Git ist ein hochwertiges Versionskontrollsystem. Es ist in der Natur verbreitet und wird verwendet, um Änderungen im Quellcode während der Softwareentwicklung zu verfolgen. Es verfügt über ein einzigartiges Verzweigungsmodell, mit dessen Hilfe die Arbeit zwischen Entwicklern synchronisiert und Änderungen in Dateien nachverfolgt werden können.

Die Hauptziele von Git sind Geschwindigkeit, Datenintegrität und Unterstützung für verteilte, nichtlineare Workflows. Git wird auf dem lokalen Computer anstelle der Cloud installiert und gewartet.

GitHub ist ein Cloud-basierter Git-Repository-Hosting-Service, der Teams zusammenbringt. Es bietet Ihnen eine webbasierte Benutzeroberfläche sowie Zugriffskontrolle und viele Funktionen für die Zusammenarbeit, grundlegende Tools für die Aufgabenverwaltung für jedes Projekt.

Außerdem ist GitHub ein Open-Source-Code, d. H. Code wird auf einem zentralen Server gespeichert und kann von jedem aufgerufen werden.

F # 16) Was ist ein Konflikt in Git und wie kann man ihn lösen?

Antworten: Git verfügt über eine automatische Zusammenführungsfunktion, die die Zusammenführungs-Commits selbstständig verarbeitet, sofern die Codeänderungen in verschiedenen Zeilen und in verschiedenen Dateien vorgenommen wurden.

Wenn Sie jedoch um Commits konkurrieren, bei denen Änderungen in denselben Codezeilen einer Datei vorgenommen wurden oder eine Datei in einem Zweig gelöscht wurde, in einem anderen jedoch vorhanden und geändert wurde, kann Git Unterschiede nicht automatisch auflösen und führt daher zu Zusammenführungskonflikten.

In solchen Fällen ist Ihre Hilfe erforderlich, um zu entscheiden, welcher Code in die endgültige Zusammenführung aufgenommen und welcher verworfen werden soll.

Ein Zusammenführungskonflikt kann beim Zusammenführen eines Zweigs, beim erneuten Basieren eines Zweigs oder beim Auswählen eines Commits auftreten. Sobald ein Konflikt erkannt wird, hebt Git den Konfliktbereich hervor und fordert Sie auf, ihn zu lösen. Sobald der Konflikt gelöst ist, können Sie mit der Zusammenführung fortfahren.

Führen Sie die folgenden Schritte aus, um einen konkurrierenden Zusammenführungskonflikt bei Zeilenänderungen zu lösen:

1. Öffnen Sie Git Bash (Git-Befehlszeile).
2. Benutzen CD Befehl, um zum lokalen Git-Repository zu wechseln, bei dem der Zusammenführungskonflikt auftritt.
3. Verwenden Sie die Git-Status Befehl zum Erstellen der Liste der Dateien, die vom Zusammenführungskonflikt betroffen sind.
4. Öffnen Sie den von Ihnen verwendeten Texteditor und wechseln Sie zu der Datei, in der Zusammenführungskonflikte auftreten.
5. Um den Beginn des Zusammenführungskonflikts in Ihrer Datei anzuzeigen, suchen Sie im Dokument nach der Konfliktmarkierung<<<<<<<. At the point when you open the file, you’ll observe the modifications from the HEAD or base branch after the line <<<<<<>>>>>> NIEDERLASSUNGSNAME.
6. Wählen Sie für den Fall, dass Sie nur die Änderungen Ihrer Niederlassung beibehalten, nur die Änderungen der anderen Niederlassung beibehalten oder eine neue Änderung vornehmen möchten, die möglicherweise Änderungen aus den beiden Zweigen enthält. Löschen Sie die Konfliktmarkierungen<<<<<<>>>>>> und nehmen Sie die Änderungen vor, die Sie beim endgültigen Zusammenführen benötigen.
7. Benutzen Git fügt hinzu. Befehl zum Hinzufügen oder Bereitstellen Ihrer Änderungen.
8. Verwenden Sie zum Schluss die git commit -m 'Nachricht' Befehl, um Ihre Änderungen mit einem Kommentar festzuschreiben.

Um den Konflikt beim Entfernen zusammengeführter Dateien zu lösen, müssen Sie die folgenden Schritte ausführen:

1. Öffnen Sie Git Bash (Git-Befehlszeile).
2. Benutzen CD Befehl, um zum lokalen Git-Repository mit dem Zusammenführungskonflikt zu wechseln.
3. Verwenden Sie die Git-Status Befehl zum Erstellen der Liste der Dateien, die vom Zusammenführungskonflikt betroffen sind.
4. Öffnen Sie den von Ihnen verwendeten Texteditor und wechseln Sie zu der Datei, in der Zusammenführungskonflikte auftreten.
5. Wählen Sie, ob Sie die entfernte Datei behalten möchten. Sie können die letzten Änderungen, die in der entfernten Datei vorgenommen wurden, in Ihrem Texteditor überprüfen.
6. Benutzen git hinzufügen Befehl zum Hinzufügen der entfernten Datei zum Repository. Oder verwenden geh rm Befehl zum Entfernen der Datei aus Ihrem Repository.
7. Verwenden Sie zum Schluss die git commit -m 'Nachricht' Befehl, um Ihre Änderungen mit einem Kommentar festzuschreiben.

F # 17) Wie können Sie einen Broken Commit beheben?

Antworten: Um ein fehlerhaftes Commit zu beheben oder das letzte Commit zu ändern, verwenden Sie am besten den Befehl „ git commit -amend ’ .

Sie können abgestufte Änderungen mit dem vorherigen Commit kombinieren, um alternativ ein völlig neues Commit zu erstellen. Dies ersetzt das letzte Commit durch das geänderte Commit.

(Bild Quelle ))

Mit diesem Befehl können Sie auch die vorherige Festschreibungsnachricht bearbeiten, ohne den Snapshot zu ändern.

F # 18) Was nützt git instaweb?

Antworten: Es ist ein Skript, mit dem Sie Ihr funktionierendes Git-Repository sofort in einem Webbrowser durchsuchen können.

Dieses Skript richtet gitweb und einen Webserver ein, um das lokale Repository zu durchsuchen. Es leitet automatisch einen Webbrowser und führt einen Webserver über eine Schnittstelle in Ihr lokales Repository aus.

F # 19) Was ist Git Is-Tree?

Antworten: 'Git is-tree' bezeichnet ein Baumobjekt, das den Modus und den Namen aller Elemente zusammen mit dem SHA-1-Wert des Blobs oder des Baums enthält.

Q # 20) Gibt es eine Möglichkeit, ein bereits gepushtes und veröffentlichtes Git-Commit rückgängig zu machen?

Antworten: Ja, um ein fehlerhaftes Commit zu beheben oder rückgängig zu machen, gibt es zwei Ansätze, die je nach Szenario verwendet werden können.

Sie sind:

1. Der naheliegende Weg besteht darin, ein neues Commit durchzuführen, bei dem Sie die fehlerhafte Datei entfernen oder die darin enthaltenen Fehler beheben. Sobald Sie fertig sind, können Sie es in ein Remote-Repository verschieben.
2. Ein anderer Ansatz besteht darin, ein neues Commit zu erstellen, um alle Änderungen rückgängig zu machen, die im vorherigen fehlerhaften Commit vorgenommen wurden. Dies kann durch den Befehl git revert erfolgen - “ git revert '

Q # 21) Wie werden Sie zwischen Git Pull und Git Fetch unterscheiden?

Antworten: Git ziehen Der Befehl ruft alle neuen Commits aus einem bestimmten Zweig im zentralen Repository ab und aktualisiert den Zielzweig in Ihrem lokalen Repository.

Git holen zielt auch auf das Gleiche ab, jedoch ist die zugrunde liegende Funktionalität etwas anders. Wenn Sie einen Git-Abruf durchführen, werden alle neuen Commits aus einem bestimmten Zweig in Ihrem zentralen Repository abgerufen und diese Änderungen in einem neuen Zweig in Ihrem lokalen Repository gespeichert. Dies wird als abgerufene Verzweigung bezeichnet.

Wenn Sie diese Änderungen in Ihrem Zielzweig sehen möchten, müssen Sie a zusammenführen nach git holen. Der Zielzweig wird erst nach dem Zusammenführen mit dem abgerufenen Zweig mit den neuesten Änderungen aktualisiert.

Ein Git-Pull bringt also den lokalen Zweig mit seiner Remote-Version auf den neuesten Stand, während ein Git-Abruf Ihren eigenen lokalen Zweig oder Ihre eigene Arbeitskopie nicht direkt ändert refs / Köpfe. Git Fetch kann verwendet werden, um Ihre Remote-Tracking-Zweige unter zu aktualisieren refs / fernbedienungen //.

In einfachen Worten, Git Pull ist gleich Git Fetch, gefolgt von einem Git Merge .

F # 22) Wozu dient der Staging-Bereich oder die Indizierung in Git?

Antworten: Aus Git-Sicht gibt es drei Bereiche, in denen die Dateiänderungen beibehalten werden können, d. H. Arbeitsverzeichnis, Staging-Bereich und Repository.

Zunächst nehmen Sie Änderungen im Arbeitsverzeichnis Ihres Projekts vor, das auf Ihrem Computer-Dateisystem gespeichert ist. Alle Änderungen bleiben hier, bis Sie sie einem Zwischenbereich hinzufügen, der als Staging-Bereich bezeichnet wird.

Sie können die Änderungen durch Ausführen inszenieren git hinzufügen. Befehl. In diesem Staging-Bereich erhalten Sie eine Vorschau Ihres nächsten Commits und können Ihre Commits optimieren. Sie können Änderungen im Staging-Bereich hinzufügen oder entfernen, bis Sie mit der Version zufrieden sind, die Sie festschreiben möchten.

Sobald Sie Ihre Änderungen überprüft und die geänderte Phase abgemeldet haben, können Sie die Änderungen endgültig festschreiben. Beim Festschreiben gehen sie in das lokale Repository, d. H. In das Verzeichnis .git / objects.

Wenn Sie die Git-GUI verwenden, sehen Sie die Option, Ihre Änderungen vorzunehmen. Im folgenden Screenshot befindet sich die Datei sample.txt im Bereich für nicht bereitgestellte Änderungen. Dies bedeutet, dass sie sich in Ihrem Arbeitsverzeichnis befindet.

Sie können eine Datei auswählen und auf 'Bühne geändert' klicken. Anschließend wird sie in den Staging-Bereich verschoben. Zum Beispiel Die Datei hello.txt befindet sich im Bereich 'Phase geändert' (wird festgeschrieben). Sie können Ihre Änderungen überprüfen und dann eine Abmeldung vornehmen, gefolgt von einem Commit.

Staging wird auch als Indizierung bezeichnet, da git eine Indexdatei verwaltet, um die Änderungen Ihrer Dateien in diesen drei Bereichen zu verfolgen. Die bereitgestellten Dateien befinden sich derzeit in Ihrem Index.

Wenn Sie dem Staging-Bereich Änderungen hinzufügen, werden die Informationen im Index aktualisiert. Wenn Sie ein Commit durchführen, wird tatsächlich festgestellt, was im Index festgeschrieben wird und nicht, was sich im Arbeitsverzeichnis befindet. Du kannst den ... benutzen Git-Status Befehl, um zu sehen, was im Index enthalten ist.

F # 23) Was ist Git Stash?

Antworten: Der GIT-Stash erfasst den aktuellen Status des Arbeitsverzeichnisses und des Index und speichert ihn für die zukünftige Verwendung auf dem Stapel. Es setzt die nicht festgeschriebenen Änderungen (sowohl bereitgestellte als auch nicht bereitgestellte) aus Ihrem Arbeitsverzeichnis zurück und gibt Ihnen einen sauberen Arbeitsbaum zurück.

Sie können jetzt an etwas anderem arbeiten, und wenn Sie zurückkommen, können Sie diese Änderungen erneut anwenden. Wenn Sie also von einem Kontext in einen anderen wechseln möchten, ohne Ihre aktuellen Änderungen zu verlieren, können Sie Stashing verwenden.

Dies ist hilfreich beim schnellen Kontextwechsel, wenn Sie sich mitten in einer Codeänderung befinden, die Sie derzeit nicht festschreiben oder rückgängig machen möchten, und an der Sie noch etwas anderes arbeiten müssen. Der zu verwendende Befehl ist git stash.

F # 24) Was ist der Git Stash Drop?

Antworten: Wenn Sie keinen bestimmten Stash mehr benötigen, können Sie ihn durch Ausführen entfernen git stash drop befehl . Wenn Sie alle Stashes auf einmal aus dem Repository entfernen möchten, können Sie sie ausführen git stash clear befehl .

F # 25) Was ist Git Stash anwenden? Wie unterscheidet es sich von Git Stash Pop?

Antworten: Beide Befehle werden verwendet, um Ihre versteckten Änderungen erneut anzuwenden und an der Stelle zu arbeiten, an der Sie sie verlassen haben.

Im Git Stash anwenden Befehl, werden die Änderungen erneut auf Ihre Arbeitskopie angewendet und auch im Vorrat aufbewahrt. Dieser Befehl kann verwendet werden, wenn Sie dieselben versteckten Änderungen auf mehrere Zweige anwenden möchten.

Im Git Stash Pop Befehl werden die Änderungen aus dem Stash entfernt und erneut auf die Arbeitskopie angewendet.

F # 26) Wozu dient der Befehl git clone?

Antworten: Das Git-Klon Der Befehl erstellt eine Kopie des vorhandenen zentralen Git-Repositorys auf Ihrem lokalen Computer.

F # 27) Wann wird der Befehl git config verwendet?

Antworten: Das Git-Konfiguration Mit dem Befehl werden Konfigurationsoptionen für Ihre Git-Installation festgelegt.

Zum Beispiel, Nachdem Sie Git heruntergeladen haben, müssen Sie die folgenden Konfigurationsbefehle verwenden, um den Benutzernamen und die E-Mail-Adresse in Git festzulegen:

$ git config –global user.name “”

$ git config –global user.email “”

Mit diesem Befehl können also hauptsächlich Dinge wie das Verhalten des Repositorys, Benutzerinformationen und Einstellungen eingerichtet werden.

F # 28) Wie können Sie feststellen, ob der Zweig bereits mit dem Master zusammengeführt wurde?

Antworten:

Durch Ausführen der folgenden Befehle können Sie den Status der Zweigzusammenführung kennenlernen:

1. Git Branch - Merged Master: Dadurch werden alle Zweige aufgelistet, die in master umbenannt wurden.
2. git branch –merged: Dadurch werden alle Zweige aufgelistet, die in HEAD zusammengeführt wurden.
3. Git-Zweig - nicht zusammengeführt: Dadurch werden alle Zweige aufgelistet, die noch nicht zusammengeführt wurden.

Standardmäßig gibt dieser Befehl nur den Zusammenführungsstatus lokaler Zweige an. Wenn Sie sowohl den Status der lokalen als auch der Remote-Zweigstelle kennenlernen möchten, können Sie verwenden -zu Flagge. Wenn Sie nur nach Remote-Zweigen suchen möchten, können Sie verwenden -r Flagge.

F # 29) Was sind Hooks in Git?

Antworten: Git-Hooks sind bestimmte Skripte, die Git vor oder nach einem Ereignis wie Festschreiben, Push, Aktualisieren oder Empfangen ausführt. Sie finden den Ordner 'hooks' im Verzeichnis '.git' in Ihrem lokalen Repository. Die integrierten Skripte finden Sie hier vor dem Festschreiben, nach dem Festschreiben, vor dem Push und nach dem Push.

Diese Skripte werden lokal vor oder nach dem Auftreten eines Ereignisses ausgeführt. Sie können diese Skripte auch nach Ihren Wünschen ändern, und Git führt das Skript aus, wenn dieses bestimmte Ereignis eintritt.

F # 30) Was ist die Verwendung von Git-Gabel? Wie unterscheidet sich das Gabeln vom Klonen?

Antworten: Ein Projekt zu verzweigen bedeutet, eine entfernte, serverseitige Kopie des ursprünglichen Repositorys zu erstellen. Sie können diese Kopie umbenennen und ein neues Projekt erstellen, ohne das ursprüngliche Projekt zu beeinträchtigen. Die Gabel ist nicht das Kernkonzept von Git.

Die Gabeloperation wird vom Git-Workflow verwendet und diese Idee existiert länger für kostenlose Open-Source-Software wie GitHub. Wenn Sie das Projekt einmal gegabelt haben, werden Sie im Allgemeinen selten wieder zum übergeordneten Projekt beitragen.

Zum Beispiel, OpenBSD ist ein Unix-ähnliches Open-Source-Betriebssystem, das durch das Verzweigen von NetBSD entwickelt wurde, einem anderen Unix-ähnlichen Open-Source-Betriebssystem.

In der Verzweigung besteht jedoch eine direkte Verbindung zwischen Ihrer gegabelten Kopie und dem ursprünglichen Repository. Sie können jederzeit mithilfe der Pull-Anforderungen einen Beitrag zum ursprünglichen Projekt leisten.

In der gegabelten Kopie werden alle Hauptdaten wie Codes und Dateien aus dem ursprünglichen Repository kopiert, Verzweigungen, Pull-Anforderungen und andere Funktionen werden jedoch nicht kopiert. Forking ist ein idealer Weg für die Open Source-Zusammenarbeit.

Das Klonen ist im Wesentlichen ein Git-Konzept. Ein Klon ist eine lokale Kopie eines Remote-Repositorys. Wenn wir ein Repository klonen, wird das gesamte Quell-Repository zusammen mit seinem Verlauf und seinen Zweigen auf unseren lokalen Computer kopiert.

Im Gegensatz zum Forking besteht keine direkte Verbindung zwischen dem geklonten Repository und dem ursprünglichen Remote-Repository. Wenn Sie Pull-Anforderungen ausführen und zum ursprünglichen Projekt zurückkehren möchten, sollten Sie sich als Mitarbeiter in das ursprüngliche Repository aufnehmen lassen.

Das Klonen ist auch eine großartige Möglichkeit, eine Sicherung des ursprünglichen Repositorys zu erstellen, da die geklonte Kopie auch den gesamten Festschreibungsverlauf enthält.

F # 31) Wie können Sie herausfinden, welche Dateien in einem bestimmten Git-Commit geändert wurden?

Antworten: Mithilfe des Hashwerts des jeweiligen Commits können Sie den folgenden Befehl ausführen, um die Liste der Dateien abzurufen, die in einem bestimmten Commit geändert wurden:

git diff-tree -r {hash}

Dadurch werden alle geänderten Dateien sowie die hinzugefügten Dateien aufgelistet. Das Flag -r wird verwendet, um einzelne Dateien zusammen mit ihrem Pfad aufzulisten, anstatt sie nur in ihren Stammverzeichnisnamen zu reduzieren.

Sie können auch den folgenden Befehl verwenden:

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

–No-commit-id trainiert die Commit-Hash-Nummern, die in der Ausgabe erscheinen sollen. Während -name die Dateipfade ausschließt und nur die Dateinamen in der Ausgabe angibt.

Q # 32) Was ist der Unterschied zwischen git checkout (Filialname) und git checkout -b (Filialname)?

Antworten: Der Befehl Git Checkout (Filialname) wechselt von einem Zweig zum anderen.

Der Befehl Git Checkout -b (Filialname) erstellt einen neuen Zweig und wechselt auch zu diesem.

F # 33) Was ist SubGit?

Antworten: SubGit ist ein Tool, das für die Migration von SVN zu Git verwendet wird. Es wird von einer Firma namens TMate entwickelt. Es konvertiert die SVN-Repositorys in Git und ermöglicht es Ihnen, auf beiden Systemen gleichzeitig zu arbeiten. Der SVN wird automatisch mit Git synchronisiert.

(Bild Quelle ))

Mit diesem Tool können Sie einen SVN || Git-Spiegel erstellen. SubGit sollte auf Ihrem Git-Server installiert sein. Es erkennt alle Einstellungen Ihres Remote-SVN-Repositorys, einschließlich SVN-Revisionen, Verzweigungen und Tags, und konvertiert sie in Git-Commits.

Außerdem wird der Verlauf beibehalten, einschließlich der Verfolgung von Zusammenführungsdaten.

F # 34) Können Sie einen gelöschten Zweig in Git wiederherstellen?

Antworten: Ja, du kannst. Um einen gelöschten Zweig wiederherzustellen, sollten Sie den SHA auf der Oberseite Ihres Kopfes kennen. SHA oder Hash ist eine eindeutige ID, die Git bei jeder Operation erstellt.

Wenn Sie einen Zweig löschen, wird der SHA auf dem Terminal angezeigt:

Zweig gelöscht (war)

Mit dem folgenden Befehl können Sie den gelöschten Zweig wiederherstellen:

Git Checkout -b

Wenn Sie den SHA für das Commit an der Spitze Ihrer Filiale nicht kennen, können Sie zuerst den verwenden Reflog gehen Befehl, um den SHA-Wert zu kennen, und wenden Sie dann den obigen Checkout-Befehl an, um Ihren Zweig wiederherzustellen.

F # 35) Was ist Git Diff Befehl? Wie unterscheidet es sich von Git-Status?

Antworten: Git diff ist ein Mehrzweckbefehl, der ausgeführt werden kann, um die Unterschiede zwischen zwei beliebigen Commits, Änderungen zwischen dem Arbeitsbaum und einem Commit, Änderungen zwischen dem Arbeitsbaum und einem Index, Änderungen zwischen zwei Dateien, Änderungen zwischen dem Index und einem Baum usw. anzuzeigen.

Das Git-Status Befehl wird verwendet, um ein Repository zu überprüfen. Es zeigt den Status des Arbeitsverzeichnisses und des Staging-Bereichs. Es werden die Dateien aufgelistet, die bereitgestellt wurden, die nicht bereitgestellt wurden, und die Dateien, die nicht verfolgt wurden.

F # 36) Was enthält ein Commit-Objekt?

Antworten: Das Festschreibungsobjekt enthält den Baumobjekt-Hash der obersten Ebene, den übergeordneten Festschreibungs-Hash (falls vorhanden), Autoren- und Festschreibungsinformationen, das Festschreibungsdatum und die Festschreibungsnachricht.

Sie können dies durch die anzeigen Git Log Befehl.

Beispiel:

(Bild Quelle ))

F # 37) Was ist Git Cherry-Pick? In welchen Szenarien kann Git Cherry-Pick verwendet werden?

Antworten: Git Kirschbaum ist ein leistungsstarker Befehl zum Anwenden der Änderungen, die durch ein oder mehrere vorhandene Commits eingeführt wurden. Sie können ein Commit aus einem Zweig auswählen und auf einen anderen anwenden.

Git Cherry-Pick CommitSha ist der Befehl zum Pflücken von Kirschen. commitSha ist die Commit-Referenz.

Dieser Befehl kann zum Rückgängigmachen von Änderungen verwendet werden. Wenn Sie beispielsweise versehentlich eine Festschreibung für einen falschen Zweig vorgenommen haben, können Sie die richtige Verzweigung überprüfen und die Festschreibung dort auswählen, wo sie hingehört.

Es kann auch in der Teamzusammenarbeit verwendet werden. Es kann Szenarien geben, in denen derselbe Code von zwei Komponenten des Produkts gemeinsam genutzt werden muss. Wenn in diesem Fall ein Entwickler diesen Code bereits geschrieben hat, kann der andere den gleichen Code auswählen.

Cherry-Picking ist auch nützlich bei Bug-Hotfixes, bei denen ein Patch-Commit direkt in den Master-Zweig gepickt werden kann, um das Problem so schnell wie möglich zu beheben.

F # 38) Wofür wird 'Git Reset' verwendet? Was ist der Standardmodus dieses Befehls?

Antworten: Git zurückgesetzt ist ein leistungsstarker Befehl zum Rückgängigmachen lokaler Änderungen am Status eines Git-Repos. Dieser Befehl setzt den aktuellen HEAD auf die angegebene Stufe zurück.

Es setzt sowohl den Index als auch das Arbeitsverzeichnis auf den Status Ihres letzten Commits zurück. Git Reset hat drei Modi, d. H. Weich, hart und gemischt. Die Standardbetriebsart ist gemischt.

F # 39) Was ist der Unterschied zwischen 'HEAD', 'Working Tree' und 'Index'?

Antworten: Der Arbeitsbaum oder Arbeitsbereich ist das Verzeichnis, das die Quelldateien enthält, an denen Sie gerade arbeiten.

Der Index ist der Staging-Bereich in Git, in dem die Commits vorbereitet werden. Es liegt zwischen dem Commit und Ihrem Arbeitsbaum. Der Git-Index ist eine große Binärdatei, die alle Dateien im aktuellen Zweig, ihre Namen, sha1-Prüfsummen und Zeitstempel auflistet.

Diese Datei befindet sich unter /.git/index. HEAD ist die Referenz oder der Zeiger auf das letzte Commit im aktuellen Checkout-Zweig.

F # 40) Was ist der Unterschied zwischen Rebase und Merge? Wann sollten Sie neu gründen und wann sollten Sie zusammenführen?

Antworten: Sowohl Rebase- als auch Merge-Befehle werden verwendet, um Änderungen von einem Zweig in einen anderen zu integrieren, jedoch auf unterschiedliche Weise.

Angenommen, Sie haben Commits (dies ist vor dem Zusammenführen / Wiederherstellen). Nach dem Zusammenführen erhalten Sie das Ergebnis als Kombination von Commits. Es verbindet die Historien beider Zweige und erstellt ein neues 'Merge Commit' im Feature-Zweig.

Auf der anderen Seite verschiebt Rebase den gesamten Feature-Zweig, um an der Spitze des Master-Zweigs zu beginnen.

(Bild Quelle ))

Commits sehen folgendermaßen aus:

Ein erneutes Basieren wird für öffentliche Zweige nicht empfohlen, da inkonsistente Repositorys erstellt werden. Eine Neuausrichtung ist jedoch eine gute Option für private Niederlassungen / einzelne Entwickler. Es ist nicht sehr gut für den Branch-per-Feature-Modus geeignet. Wenn Sie jedoch ein Branch-per-Developer-Modell haben, schadet das erneute Basieren nicht.

Rebase ist auch eine destruktive Operation, daher sollte Ihr Entwicklungsteam über die erforderlichen Kenntnisse verfügen, um sie korrekt anzuwenden. Andernfalls kann engagierte Arbeit verloren gehen.

Darüber hinaus ist das Zurücksetzen einer Zusammenführung einfacher als das Zurücksetzen einer Rebase. Wenn Sie also wissen, dass möglicherweise Möglichkeiten zum Zurücksetzen erforderlich sind, sollten Sie die Zusammenführung verwenden.

Beim Zusammenführen bleibt der Verlauf unverändert, während beim erneuten Basieren der Verlauf neu geschrieben wird. Wenn Sie also den Verlauf vollständig so anzeigen möchten, wie er aufgetreten ist, sollten Sie die Zusammenführung verwenden.

F # 41) Wie lautet die Syntax für die Neubasierung?

Antworten: Die Syntax für den Rebase-Befehl lautet git rebase (new-commit)

F # 42) Wie können Sie eine Datei aus Git entfernen, ohne sie tatsächlich aus Ihrem lokalen Dateisystem zu entfernen?

Antworten: Sie können hierfür die Option 'zwischengespeichert' verwenden:

git rm -rf –cached $ FILES

Dieser Befehl entfernt die Dateien aus Ihrem Repository, ohne sie von Ihrer Festplatte zu löschen.

F # 43) Was ist das übliche Verzweigungsmuster in Git?

Antworten: Das gemeinsame Verzweigungsmuster basiert auf dem Git-Flow. Es hat zwei Hauptzweige, d. H. Master und Entwicklung.

• Der Hauptzweig enthält den Produktionscode. Der gesamte Entwicklungscode wird zu einem bestimmten Zeitpunkt in den Hauptzweig eingefügt.
• Der Entwicklungszweig enthält den Vorproduktionscode. Wenn die Funktionen abgeschlossen sind, werden sie in der Regel über eine CI / CD-Pipeline mit dem Hauptzweig zusammengeführt.

Dieses Modell hat auch einige unterstützende Zweige, die während des Entwicklungszyklus verwendet werden:

• Feature-Zweige / Themen-Zweige: Sie werden verwendet, um neue Funktionen für kommende Versionen zu entwickeln. Es kann vom Entwicklungszweig abzweigen und muss wieder in den Entwicklungszweig zusammengeführt werden. Im Allgemeinen existieren diese Zweige nur in Entwickler-Repositorys und nicht im Ursprung.
• Hotfix-Zweige: Sie werden für ungeplante Produktionsversionen verwendet, wenn ein kritischer Fehler in der Live-Prod-Version sofort behoben werden muss. Sie können vom Master abzweigen und müssen wieder zu Develop und Master zusammengeführt werden.
• Zweige freigeben: Sie werden zur Vorbereitung einer neuen Produktionsversion verwendet. Über den Release-Zweig können Sie kleinere Fehlerbehebungen vornehmen und Metadaten für die Veröffentlichung vorbereiten. Sie können von der Entwicklung abzweigen und müssen wieder in Master und Entwicklung zusammengeführt werden.

Fazit

Wir haben die wichtigen Fragen, die in Git-Interviews in diesem Tutorial allgemein gestellt werden, durchgearbeitet.

Dies hilft Ihnen nicht nur, sich auf bevorstehende Interviews vorzubereiten, sondern klärt auch Ihre Git-Konzepte.

Alles Gute für dein Interview!

Literatur-Empfehlungen

• Interview Fragen und Antworten
• Einige interessante Fragen zu Softwaretests
• Top 40 C Programming Interview Fragen und Antworten
• Die 40 beliebtesten Fragen und Antworten zum J2EE-Interview, die Sie lesen sollten
• Fragen und Antworten zum ETL-Testinterview
• 20+ am häufigsten gestellte Fragen und Antworten zum Exit-Interview
• Die wichtigsten Fragen zum Vorstellungsgespräch für Oracle Forms and Reports
• Einige knifflige manuelle Testfragen und -antworten