Häufig gestellte Fragen zu Git

Stellen Sie zunächst sicher, dass Sie ein origin-Repository konfiguriert haben. Dies sollte der Fall sein, wenn Sie Ihr Repository mit git clone geklont haben. Wenn Sie eine Verzweigung auschecken, die lokal nicht vorhanden ist, prüft Git, ob es eine Remote-Verzweigung mit demselben Namen gibt. Wenn dies der Fall ist, erstellt Git eine lokale Verzweigung mit einem Verweis auf die Remote-Verzweigung. Verwenden Sie git pull, um die Commits herunterzuladen und den Verzweigungsverlauf lokal zu aktualisieren.

Führen Sie git branch ohne Argumente aus, um die lokalen Verzweigungen anzuzeigen und dabei diejenigen hervorzuheben, die Sie ausgecheckt haben. In Visual Studio zeigt die Statusleiste auch die aktuelle Verzweigung an, wenn Sie mit einem in einem lokalen Git-Repository gespeicherten Projekt arbeiten.

Es empfiehlt sich, separate Commits für logisch unterschiedliche Änderungen vorzunehmen. Stellen Sie sich Commits als Einträge in einem Logbuch vor. Wenn Sie eine wichtige Änderung vornehmen, notieren Sie sie in einem Commit. Eine beliebte Vorgehensweise besteht darin, häufige lokale Commits zuzulassen, aber sie mittels Rebasing durchzuführen, bevor sie gepusht werden. Dies sorgt für Flexibilität und gleichzeitig für einen optimierte Commit-Verlauf.

Große Projekte mit vielen Commits und Beitragenden können zu einer main Verzweigungshistorie führen, die mehr die Entwicklung von Themenverzweigungen als das Gesamtprojekt widerspiegelt. Git ermöglicht Ihnen, Commits auf Verzweigungen zu komprimieren, durch Squashing und Rebasing von Commits. Das Squashing von Commits macht den Verzweigungsverlauf weniger ausführlich und vereinfacht den Commit-Verlauf auf der Hauptverzweigung nach dem Zusammenführen.

Verwenden Sie den git blame-Befehl, um herauszufinden, wer eine bestimmte Änderung an einer Datei vorgenommen hat. In Ihrem lokalen Repository können Sie git blame mit dem -L-Parameter ausführen und angeben, welche Zeilen von Interesse sind. Blame generiert eine formatierte Ausgabe mit dem Commit, der die Zeile zuletzt aktualisiert hat, sowie dem Namen der Person, die den Commit vorgenommen hat.

> git blame Example_repo -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Example User 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Example User 2015-11-21 09:54:23 -0800 22) line 22 of the code

Blame durchsucht den Commitverlauf für Sie. Sie können den Verlauf einer Datei auch im Webportal überprüfen, um zu bestimmen, wer eine Änderung vorgenommen hat und wann. Öffnen Sie Code Explorer für Ihr Repository und Ihre Verzweigung, und wählen Sie dann die gewünschte Datei aus. Azure Repos zeigt einen vollständigen Commit-Verlauf für diese Datei in der aktuellen Verzweigung an.

Das Auschecken einer anderen Verzweigung in Git wirkt sich auf den Zustand der Dateien in Ihrem Dateisystem aus. Git verwendet den Commitverlauf, um sicherzustellen, dass Sie mit den Dateien arbeiten, die den Status Ihrer Verzweigung repräsentieren. Wenn Sie versuchen, Verzweigungen zu ändern, während nicht committete Änderungen vorliegen, werden diese Änderungen beim Check-Out überschrieben. Da Git nicht möchte, dass Sie Ihre Änderungen versehentlich verlieren, wird der Check-Out-Vorgang verhindert. Sie haben zwei Möglichkeiten:

• Verwerfen Sie die Änderungen, und kehren Sie zum letzten Commit zurück. Anleitungen zum Zurücksetzen auf den neuesten Commit finden Sie unter Rückgängigmachen von Änderungen in Git.
• Führen Sie für die Änderungen einen Commit aus. Weitere Informationen finden Sie unter Speichern Ihrer Arbeit in Git mit Commits.
• Führen Sie Stash für Ihre aktuelle Arbeit aus, speichern Sie die Änderungen zur späteren Verwendung, und bereinigen Sie den Arbeitsbereich bis zum letzten Commit.

Dieses Problem hängt mit Zusammenführungskonflikten in großen Binärdateien zusammen. Der aktuelle Grenzwert für Dateien beträgt 100 MB. Die Problemumgehung besteht darin, Zusammenführungskonflikte lokal zu lösen, indem sie das Ziel lokal in die Quelle zusammenführen, Konflikte lösen und die Änderungen pushen.

Git LFS (Large File Storage) wird empfohlen, um große Binärdateien zu speichern, nicht nur, um Konflikte zu vermeiden, sondern auch um die Gesamtgröße des Repositorys zu verwalten, die sich auf Klon- und Pushzeiten auswirkt.

Wenn Sie Ihre Änderungen ohne Commit speichern möchten, verwenden Sie Git stash. Stash speichert die derzeit bereitgestellten und nicht bereitgestellten Änderungen in Ihrer Verzweigung und versetzt Ihre Verzweigung anschließend wieder zurück in den Zustand des letzten Commits. Sie können dann zu einer anderen Verzweigung wechseln, Ihre Arbeit durchführen und später stash apply ausführen, um Ihre Änderungen wiederherzustellen.

git stash
Saved working directory and index state WIP on feature1: be26067 updated endpoint docs
HEAD is now at be26067

Wenn Sie [git stash apply] ausführen, werden die neuesten Änderungen, für die ein Stash ausgeführt wurde, auf Ihre aktuelle Verzweigung angewendet. Wenn es einen Konflikt gibt, stellt [stash] die Änderungen für die Dateien wieder her, bei denen kein Konflikt besteht, und erstellt Konfliktmarkierungen in den Dateien, bei denen ein Konflikt vorliegt. In diesem Fall sollten Sie die Änderungen manuell mergen .

Nachdem Sie mit dem Stash fertig sind, löschen Sie ihn mit [git stash drop]. Mit diesem Befehl wird der letzte Satz von Stash-Änderungen entfernt.

Sie können über mehrere Stashes verfügen, aber dies erfordert mehr manuellen Aufwand, weil Sie Stashes explizit anwenden und löschen müssen. Weitere Informationen finden Sie in der Git Stash-Dokumentation.

Standardmäßig verwendet Befehlszeilen-Git einen Befehlszeilen-Editor, wenn Sie nach Commit-Meldungen fragen, Rebases oder andere Aufgaben ausführen, für die zusätzliche Informationen erforderlich sind. Der Standard-Editor wird mit git config konfiguriert:

> git config core.editor _path_to_editor_ _options_to_editor_

Git für Windows macht es einfach, den Editor als Editor festzulegen:

> git config core.editor notepad

Mit diesem Befehl wird der Windows-Editor konfiguriert, um Git-Informationen nach Bedarf zu bearbeiten und den Text ordnungsgemäß von Git an den Editor zu übergeben. Sie können auch Folgendes angeben

> git config format.commitMessageColumns 72 

Beibehalten der bevorzugten 72 Textspalten in den Commitnachrichten und Zeilenumbruch nach Erreichen dieses Zeichengrenzwerts für eine Zeile.

Git fügt einen Benutzernamen und E-Mail-Adressinformationen in jeden Commit ein, und Azure Repos verwendet diese Informationen beim Anzeigen von Commits sowie beim Arbeiten mit Pull Requests. Wenn Sie in der Befehlszeile arbeiten, können Sie den angezeigten Namen und die E-Mail-Informationen mit dem Befehl git config aktualisieren:

> git config --global user.email "example-user@example-site.com"
> git config --global user.name "Example User"

Die --global-Option legt die E-Mail-Adresse und den Namen fest, die in Commits für alle Git-Repositorys in diesem System enthalten sind. Wenn Sie die Einstellungen für ein einzelnes Repository ändern möchten, müssen Sie in das Verzeichnis wechseln, in dem sich das Git-Repository befindet, und die oben genannten Befehle ohne das --global-Flag ausführen.

Sie können den Namen und die E-Mail-Einstellungen auch in Visual Studio ändern. Wählen Sie im Git-Menü die Option Einstellungen aus. Wählen Sie im Dialogfeld Optionen die Option Globale Git-Einstellungen oder Git-Repositoryeinstellungen>Allgemein aus.

Visual Studio 2019, Version 16.8 und höher, bietet eine Benutzeroberfläche für Git-Versionskontrolle, während die Git-Benutzeroberfläche von Team Explorer beibehalten wird. Um Team Explorer zu verwenden, deaktivieren Sie in der Menüleiste Extras>Optionen>Vorschaufeatures>Neue Git-Benutzeroberfläche. Sie können Git-Features über beide Schnittstellen austauschbar verwenden.

Wählen Sie in Team Explorer Einstellungen und unter Git den Link Globale Einstellungen oder Repositoryeinstellungen aus.