Häufig gestellte Fragen zu Git

Stellen Sie zunächst sicher, dass Sie ein origin-Repository konfiguriert haben. Sie sollten über ein solches Repository verfügen, wenn Sie ihr Repository geklont (git clone) haben. Wenn Sie einen Branch auschecken, der lokal nicht vorhanden ist, bestimmt Git, ob es einen Remotebranch mit demselben Namen gibt. Wenn dies der Fall ist, erstellt Git einen lokalen Branch mit einem Verweis auf den Remotebranch mit diesem Namen. Verwenden Sie git pull, um die Commits herunterzuladen und Git den Branchverlauf lokal nachvollziehen zu lassen.

git branch ohne Argumente zeigt die lokalen Branches an und hebt die von Ihnen ausgecheckten Branches hervor. In Visual Studio zeigt die Statusleiste auch den aktuellen Branch an, wenn Sie mit einem Projekt arbeiten, das in einem lokalen Git-Repository gespeichert ist.

Die akzeptierte Praxis besteht darin, separate Commits für logisch getrennte Änderungen vorzunehmen. Stellen Sie sich Commits als Einträge in einem Logbuch vor. Wenn Sie eine beachtenswerte Änderung vornehmen, notieren Sie sie in einem Commit. Eine beliebte Option besteht darin, jedem Benutzer zu erlauben, so viel Code wie er möchte lokal zu committen, aber bevor er die lokalen Commits pusht, führt er für sie zunächst Squashing über Rebasing aus. Diese Option bietet Benutzern die Flexibilität, häufige Commits durchzuführen, während der Commitverlauf optimiert bleibt.

Große Projekte mit vielen Commits und einer Reihe von Mitwirkenden können zu Commitverläufen für den main-Branch führen, die die Entwicklungsgeschichte der Themenbranches, die in main zusammengeführt wurden, mehr darstellen als die Entwicklungsgeschichte des Gesamtprojekts. Git bietet eine Möglichkeit zum Verdichten von Commits für Branches durch Squashing von Commits und Rebasing. Wenn Sie für Commits Squashing ausführen, wird der Commitverlauf für einen Branch weniger ausführlich, was einen einfacheren Commitverlauf für den main-Branch nach dem Mergen ermöglicht.

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 foo.js -L 20,+40  # show the blame output for the next 40 lines starting at line 20

215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 20) line 20 of the code
215d1108 (Francis Totten 2015-11-21 09:54:23 -0800 21) line 21 of the code
215d1108 (Francis Totten 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 Ihren Branch, und wählen Sie dann die gewünschte Datei aus. Azure Repos zeigt einen vollständigen Commitverlauf für diese Datei im aktuellen Branch an.

Das Auschecken eines anderen Branch 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 Ihres Branch darstellen. Wenn Sie versuchen, Branches 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.

Manchmal möchten Sie die Änderungen beibehalten, aber nicht committen, weil Sie noch nicht dazu bereit sind. Verwenden Sie Git stash. Stash übernimmt die aktuellen gestageten und nicht gestageten Änderungen in Ihrem Branch und speichert die Arbeit. Anschließend wird ihr Branch wieder zurück in den Zustand des letzten Commits versetzt. Sie können zum anderen Branch wechseln, Ihre Arbeit erledigen, und dann, wenn Sie zu diesem Branch zurückkehren, 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 Stash ausgeführt wurde, auf Ihren aktuellen Branch angewendet. Wenn es beim Anwenden der Änderungen, für die Stash ausgeführt wurde, zu einem Konflikt kommt, stellt stash die Änderungen für die Dateien wieder her, die keinen Konflikt verursachen, und erstellt Konfliktmarkierungen in den Dateien, die einen Konflikt verursachen, damit Sie ihn beseitigen können. In diesem Fall sollten Sie die Änderungen manuell mergen .

Sobald Sie mit dem Ausführen des Stash fertig sind, löschen Sie ihn mit git stash drop. Dieser Befehl entfernt die letzte Gruppe mit Änderungen,für die Stash ausgeführt wurde.

Sie können über mehrere Stashes verfügen, aber dies erfordert mehr manuelle Bearbeitung, 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 Commitnachrichten 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 "frank@fabrikam.com"
> git config --global user.name "Francis Totten"

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.