Q1. Wie kannst du deine aktuelle Git-Version überprüfen?

• git --v
• git --version
• git --option
• git --current

Referenz

Q2. Welcher Befehl ermöglicht es dir, eine Verbindung zwischen einem lokalen und einem Remote-Repository herzustellen?

• git remote add new
• git remote add origin
• git remote new origin
• git remote origin

Referenz

Q3. Beschreibe, was diese Git-Befehle mit dem Commit-Verlauf machen:

git reset --hard HEAD~5
git merge --squash HEAD@{1}

• Sie setzen HEAD auf den fünften Commit im Repo zurück und führen dann eine Zusammenführung mit dem Master-Zweig durch.
• Der aktuelle HEAD des aktuellen Branches wird fünf Commits zurückgesetzt, dann werden frühere Commits zu einem einzigen Commit zusammengefasst.
• Sie löschen die letzten fünf Commits.
• Sie führen die letzten fünf Commits in einen neuen Branch zusammen.

Erklärung:

• git reset --hard HEAD~5 setzt den aktuellen Branch auf den Commit direkt vor den letzten 5 zurück (siehe man gitrevisions für Details zu dieser Notation und anderen coolen Alternativen wie HEAD@{2 days ago}). Da es sich um ein hartes Zurücksetzen handelt, werden auch alle Änderungen im Arbeitsverzeichnis überschrieben. Siehe man git-reset.
• git merge --squash HEAD@{1} HEAD@{1} ist der Ort, an dem der Branch gerade vor dem vorherigen Befehl war (nochmals, siehe man gitrevisions). Dieser Befehl setzt den Zustand des Index auf den Stand, den er direkt nach einer Zusammenführung von diesem Commit hätte. Diese gesamte Operation könnte eine Möglichkeit sein, 5 Commits von einem Branch zu nehmen, in dem du ein neues Feature gestartet hast, und sie zu einem einzigen, aussagekräftigen Commit zusammenzufassen.

Referenz

Q4. Dein aktuelles Projekt hat mehrere Branches; master, beta und push-notifications. Du hast gerade das Benachrichtigungs-Feature im push-notification-Branch fertiggestellt und möchtest es in den Beta-Branch übernehmen. Wie kannst du das erreichen?

• Wechsel zum push-notifications-Branch und führe git merge beta aus
• Wechsel zum Master-Branch und führe git merge beta -> push-notifications aus
• Lösche den push-notifications-Branch und er wird automatisch in den Master-Branch übernommen
• Wechsel zum Beta-Branch und führe git merge push-notifications aus

Referenz

Q5. Welche der folgenden Aussagen trifft zu, wenn du den folgenden Befehl verwendest?

git add -A

• Alle neuen und aktualisierten Dateien werden zum Stage-Bereich hinzugefügt
• Dateien werden in alphabetischer Reihenfolge gestaged.
• Alle neuen Dateien werden zum Stage-Bereich hinzugefügt
• Nur aktualisierte Dateien werden gestaged

Referenz Referenz

Q6. Was wird der folgende Befehl in der Terminalausgabe anzeigen?

git remote -v

• Eine Liste der Remote-Repositorys und ihrer URLs
• Die aktuelle Git-Version, die du gerade ausführst
• Einen Inline-Editor zum Bearbeiten von Remote-Repositorys
• Die letzten 5 Git-Versionen, die du installiert hast

Referenz Referenz

Q7. Schau dir die folgenden Befehle an und beschreibe, was passiert.

git checkout feature-user-location
git cherry-pick kj2342134sdf090093f0sdgasdf99sdfo992mmmf9921231

• Der Commit wird für die Veröffentlichung im feature-user-location-Branch markiert
• Ein Commit wird von seinem ursprünglichen Branch zum feature-user-location-Branch kopiert
• Der Commit wird als neuer HEAD des Commit-Verlaufs ausgewählt
• Ein Commit wird vom feature-user-location-Branch zum Master-Branch kopiert
• Der Branch wird auf den feature-user-location-Branch umgeschaltet, und der angegebene Commit wird auf den Branch angewendet.

Erklärung:

'git checkout feature-user-location' wechselt zum 'feature-user-location'-Branch. 'git cherry-pick kj2342134sdf090093f0sdgasdf99sdfo992mmmf9921231' wendet die Änderungen des angegebenen Commits ('kj2342134sdf090093f0sdgasdf99sdfo992mmmf9921231') auf den aktuellen Branch (feature-user-location) an. Dadurch wird der Commit effektiv von seinem ursprünglichen Branch zum feature-user-location-Branch kopiert. Diese Sequenz von Befehlen führt also ein Cherry-Picking eines bestimmten Commits auf den feature-user-location-Branch durch.

Q8. Was macht der folgende Befehl im Git-Repository?

git reset --soft HEAD^

• Er löscht alle vorherigen Commits und setzt den Repository-Verlauf auf seinen ursprünglichen Zustand zurück.
• Er setzt den Arbeitsbranch auf den ersten Commit zurück.
• Er behält HEAD beim aktuellen Commit, löscht jedoch alle vorherigen Commits.
• Er setzt HEAD auf den vorherigen Commit zurück und lässt die Änderungen des ungeschehen gemachten Commits im Staging-Bereich.

Referenz Referenz

Q9. Du findest einen Fehler in deinem Projekt, kannst aber nicht feststellen, wo er im Commit-Verlauf eingeführt wurde. Wie würdest du dieses Problem diagnostizieren?

• Manuell durchsuchst du deinen Commit-Verlauf.
• Verwende git search -diff, um alle Commits im Verlauf deines Repositorys zu vergleichen.
• Führe einen Git-Rebase durch, um den fehlerhaften Commit zu finden.
• Verwende git bisect, um den fehlerhaften Commit mit einem früheren Commit zu vergleichen, der wie erwartet funktioniert.

Referenz Referenz

Q10. Warum würde der folgende Befehl verwendet?

git rebase -i HEAD~10

• Um eine vergleichende Suche der letzten 10 Commits nach Unterschieden durchzuführen
• Um die letzten 10 Commits aufzulisten und sie entweder mit dem Squash- oder Fixup-Befehl zu ändern
• Um die letzten 10 Commits zu löschen und HEAD zurückzusetzen
• Um die letzten 10 Commits lokal zu zwischenspeichern

Referenz Referenz

Q11. Warum würdest du einen Pre-Receive-Hook in deinem Remote-Repository verwenden?

• Du würdest es nicht verwenden, du würdest es im lokalen Repository verwenden
• Um ein Skript auszuführen, wenn ein Remote einen Push empfängt, der ausgelöst wird, bevor irgendwelche Referenzen aktualisiert werden
• Um ein Skript auszuführen, nachdem Updates im Remote-Repository vorgenommen wurden
• Um alle Commit-Tags und Versionsveröffentlichungen zu debuggen

Referenz Referenz

Q12. Welche Option kannst du verwenden, um Git-Konfigurationen in deiner gesamten Git-Umgebung anzuwenden?

• --all
• --master
• --global
• --update

Referenz Referenz

Q13. Wie könntest du mehrere Commits zusammenführen, ohne git merge --squash zu verwenden?

• Caching
• Du kannst es nicht. git merge --squash ist der einzige Git-Befehl für diese Operation.
• Rebasing
• Reflogging

Referenz Referenz

Q14. Was würde passieren, wenn du ein vorhandenes Git-Repository geklont hättest?

• Eine neue Kopie würde das zentrale Repository überschreiben
• Eine Kopie des Repositorys würde auf deinem lokalen Rechner erstellt
• Nichts, das Klonen ist keine unterstützte Git-Funktion
• Eine Kopie des Repositorys würde auf der Hosting-Plattform erstellt

Referenz Referenz

Q15. Wie kannst du eine Liste der hinzugefügten oder geänderten Dateien in einem bestimmten Commit anzeigen?

• Suche den Commit im Remote-Repository, da dort diese Art von Informationen gespeichert sind.
• Verwende den Befehl diff-tree mit dem Commit-Hash.
• Führe git commit --info mit dem Commit-Hash aus.
• Greife auf die Stash-Daten des Commits mit git stash zu.

Referenz Referenz

Q16. Welche Dateien werden in diesem .gitignore ausgelassen?

#.swift
build/

*.txt
*.metadata

• Alle Dateien mit einer .swift-, .txt- oder Metadaten-Dateierweiterung sowie das gesamte Build-Verzeichnis
• Nur das Build-Verzeichnis
• Alle Dateien im Build-Verzeichnis sowie Dateien mit den Endungen .txt oder .metadata
• Nur Dateien mit den Erweiterungen .swift und .txt.

Referenz

Eine Zeile, die mit # beginnt, dient als Kommentar. Daher tut # .swift nichts. Siehe man gitignore.

Q17. Nachdem du Änderungen an einem lokalen Repository vorgenommen hast, führst du den folgenden Befehl aus. Was wird dies tun?

git commit -a -m "Refactor code base"

• Nichts, du kannst nicht mehrere Optionen im selben Befehl verwenden
• Fügt alle neuen Dateien dem Staging-Bereich hinzu
• Committe alle neuen Dateien mit einer Nachricht
• Fügt alle geänderten Dateien dem Staging-Bereich hinzu und committet sie dann mit einer Nachricht

Q18. Nachdem du deinen Git-Status überprüft hast, erhältst du die folgende Ausgabe, die die Datei beta-notes.js im Commit, aber auch nicht im Staging-Bereich zeigt. Wie kann diese Situation auftreten?

Change to be committed:

(use "git reset HEAD <file>..." to unstage)
modified: beta-notes.js
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout --<file>..." to discard changes in working directory)

modified: beta-notes.js

• Es gab zwei Kopien von beta-notes.js, aber eine wurde gelöscht
• beta-notes.js wurde gestaged und danach geändert, was zwei verschiedene Versionen der Datei erzeugte
• Zwei Kopien von beta-notes.js wurden erstellt, aber nur eine wird verfolgt
• Es gibt zwei verfolgte Kopien von beta-notes.js, aber eine wurde aus dem Commit entfernt

Referenz

Q19. Wo werden Dateien gespeichert, bevor sie dem lokalen Repository committed werden?

• Gespeicherte Dateien
• Git-Dokumente
• Staging-Bereich
• Git-Cache

Referenz

Q20. Welche Befehle würdest du verwenden, um ein Überschreiben deiner lokalen Dateien mit dem Master-Branch zu erzwingen?

• ⠀

  git pull --all
  git reset --hard origin/master

• ⠀

  git pull -u origin master
  git reset --hard master

• ⠀

  git pull origin master
  git reset --hard origin/myCurrentBranch

• ⠀

  git fetch --all
  git reset --hard origin/master

Hinweis: - Der Befehl pull ist fetch gefolgt von entweder merge oder rebase (in diesem Fall merge). Wir möchten nicht zusammenführen. Zusammenführen wäre eine Aktion für unser Repository. Wir möchten nur unsere lokalen Dateien überschreiben.