Häufig gestellte Fragen zu Git

Überprüfen Sie zunächst, ob Sie ein origin Repository konfiguriert haben. Wenn Sie Ihr Repository mit git clonegeklont haben, verfügen Sie bereits über eins. Wenn Sie eine Verzweigung auschecken, die nicht lokal vorhanden ist, bestimmt Git, ob eine Remote-Verzweigung mit demselben Namen vorhanden ist. Wenn ja, erstellt Git eine lokale Verzweigung, die auf die Remoteverzweigung verweist. 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 Branches anzuzeigen und den ausgecheckten Branch zu markieren. In Visual Studio zeigt die Statusleiste den aktuellen Branch an, wenn Sie mit einem Projekt arbeiten, das in einem lokalen Git-Repository gespeichert ist.

Nehmen Sie separate Commits für logisch unterschiedliche Änderungen vor. Stellen Sie sich Commits als Einträge in einem Logbuch vor. Wenn Sie eine bemerkenswerte Änderung vornehmen, notieren Sie sie in einem Commit. Ein beliebter Ansatz besteht darin, häufige lokale Commits zuzulassen und sie vor dem Pushen durch Rebasing zusammenzufassen. Dieser Ansatz bietet Flexibilität, während der Commitverlauf übersichtlich bleibt.

In großen Projekten mit vielen Commits und Mitwirkenden kann die Branch-Historie main die Entwicklung der Themenzweige stärker widerspiegeln als den Fortschritt des gesamten Projekts. Sie können Commits auf Branches durch Squashen und Rebasen verdichten. Das Zusammenfassen von Commits vereinfacht die Branch-Historie und führt nach dem Zusammenführen zu einem übersichtlicheren Hauptbranch.

Verwenden Sie den git blame-Befehl, um herauszufinden, wer eine bestimmte Änderung an einer Datei vorgenommen hat. Führen Sie git blame in Ihrem lokalen Repository mit dem -L-Parameter aus, um die Zeilen von Interesse anzugeben. Blame erzeugt eine formatierte Ausgabe, die das Commit anzeigt, welches jede Zeile zuletzt aktualisierte, sowie den Autor dieser Änderung.

> 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. Sie können den Verlauf einer Datei auch im Webportal überprüfen, um zu bestimmen, wer eine Änderung vorgenommen hat und wann. Öffnen Sie den Code-Explorer für Ihr Repository und Ihre Verzweigung, und wählen Sie dann die Datei aus, die Sie untersuchen möchten. Azure Repos zeigt einen vollständigen Commit-Verlauf für diese Datei im aktuellen Branch an.

Das Auschecken eines anderen Branches in Git wirkt sich auf den Zustand der Dateien im Dateisystem aus. Git verwendet den Commitverlauf, um sicherzustellen, dass Ihr Arbeitsverzeichnis mit der ausgewählten Verzweigung übereinstimmt. Wenn Sie versuchen, Verzweigungen zu ändern, während Sie keine nicht übernommenen Änderungen haben, werden diese Änderungen beim Auschecken überschrieben. Um versehentlichen Datenverlust zu verhindern, blockiert Git das Auschecken. Sie haben die folgenden Optionen:

• Verwerfen Sie die Änderungen, und kehren Sie zum letzten Commit zurück. Anweisungen zum Zurücksetzen auf den letzten Commit finden Sie unter Rückgängigmachen von Änderungen in Git .
• Führen Sie für die Änderungen einen Commit aus. Siehe Speichern Sie Ihre Arbeit in Git mit Commits.
• Stash deine aktuellen Arbeiten, um die Änderungen für später zu speichern, und setze den Arbeitsbereich auf den letzten Commit zurück.

Dieses Problem tritt aufgrund von Zusammenführungskonflikten in großen Binärdateien auf. Die aktuelle Dateigrößenbeschränkung beträgt 100 MB. Um dieses Problem zu umgehen, führen Sie das Ziel lokal mit der Quelle zusammen, lösen Konflikte, und pushen Sie die Änderungen.

Verwenden Sie Git LFS (Large File Storage) für große Binärdateien, um Konflikte zu vermeiden und die Gesamtgröße des Repositorys zu verwalten, was sich auf Klon- und Pushzeiten auswirkt.

Verwenden Sie Git stash, um Änderungen ohne Commit zu speichern. Dieser Befehl speichert die aktuellen gestagten und ungestagten Änderungen in Ihrem Zweig und setzt den Zweig auf den Zustand des letzten Commits zurück. Sie können dann zu einem anderen Branch wechseln, Ihre Arbeit abschließen 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 zuletzt zwischengespeicherten Änderungen auf Ihrer aktuellen Verzweigung angewendet. Wenn Dateien in Konflikt geraten, stash stellen Sie die nicht in Konflikt stehenden Dateien wieder her und erstellen Konfliktmarkierungen für die verbleibenden Dateien. Lösen Sie alle Konflikte manuell.

Wenn Sie den Stash nicht mehr benötigen, löschen Sie ihn mit git stash drop. Mit diesem Befehl wird der zuletzt gespeicherte Stash entfernt.

Sie können mehrere Stashes haben, jedoch müssen Sie jedes einzelne explizit anwenden und ablegen. Weitere Informationen finden Sie in der Git Stash-Dokumentation.

Standardmäßig verwendet Git einen Befehlszeilen-Editor, wenn er zur Eingabe von Commit-Nachrichten auffordert, rebases durchführt und andere Aufgaben verarbeitet, die Eingaben erfordern. Konfigurieren des Standard-Editors mit git config:

> git config core.editor _path_to_editor_ _options_to_editor_

Git für Windows erleichtert das Festlegen von Notepad als Editor:

> git config core.editor notepad

Mit diesem Befehl wird der Windows-Editor für die Textbearbeitung mit Git konfiguriert. Sie können auch eine bevorzugte Spaltenbreite für Commitnachrichten angeben:

> git config format.commitMessageColumns 72 

Diese Einstellung umschließt commit-Nachrichtentext mit der bevorzugten Breite der 72-stelligen Spalte.

Git enthält einen Benutzernamen und eine E-Mail-Adresse in jedem Commit, und Azure Repos verwendet diese Informationen, wenn er Commits und Pullanforderungen anzeigt. Verwenden Sie den git config Befehl, um den Namen und die E-Mail in der Befehlszeile zu 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. Um die Einstellungen für ein einzelnes Repository zu ändern, navigieren Sie zum Repositoryverzeichnis, und führen Sie die vorherigen Befehle ohne das --global Flag aus.

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

Aktivieren Sie die ausführliche Ablaufverfolgung, um detaillierte Fehlerinformationen zu erhalten. Legen Sie die folgenden Umgebungsvariablen fest, bevor Sie Ihren Git-Befehl ausführen:

set GIT_TRACE=1
set GIT_TRACE_PACKET=1
set GIT_CURL_VERBOSE=1

Die Ablaufverfolgungsausgabe hilft zu bestimmen, ob sich der Fehler auf Netzwerkkonnektivität, Proxykonfiguration, SSL-Zertifikate oder Authentifizierung bezieht. Weitere Informationen zu Git-Umgebungsvariablen finden Sie unter Git Internals – Umgebungsvariablen.

Wenn Sie sich hinter einem Proxyserver befinden und Git nicht dafür konfiguriert ist, ihn zu verwenden, schlagen Klon- und Pushvorgänge mit 407-Fehlern, 502-Fehlern oder mit Fehlern vom Typ "Kein Zugriff möglich" fehl.

Führen Sie die Ausführung aus git config --list , um zu überprüfen, ob ein Proxy bereits konfiguriert ist. Wenn nicht, legen Sie den Proxy global fest:

> git config --global http.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

So konfigurieren Sie einen Proxy nur für eine bestimmte URL:

> git config --global http.https://dev.azure.com.proxy http://proxyUsername:proxyPassword@proxy.server.com:port

Weitere Informationen finden Sie in der Git-Konfigurationsdokumentation.

Wenn Ihr Kennwort geändert oder zwischengespeicherte Anmeldeinformationen veraltet sind, schlagen Git-Klon- oder Pushvorgänge mit Authentifizierungsfehlern fehl. Setzen Sie den Git-Anmeldeinformations-Manager (GCM) zurück, um das Problem zu beheben:

> git config --global --unset credential.helper
> git config --global credential.helper manager

Sie können zwischengespeicherte Anmeldeinformationen auch direkt in der Windows-Anmeldeinformationsverwaltung entfernen:

1. Öffnen Sie Systemsteuerung>Benutzerkonten>Anmeldeinformations-Manager.
2. Wählen Sie Windows-Anmeldeinformationen aus.
3. Suchen und Entfernen von Einträgen für git:https://dev.azure.com/<orgname>.

Alternativ können Sie die Befehlszeile verwenden:

> cmdkey /list | findstr "git"
> cmdkey /delete:git:https://dev.azure.com/<orgname>

Führen Sie unter macOS aus git credential reject , um gespeicherte Anmeldeinformationen zu löschen:

echo url=https://dev.azure.com/<orgname> | git credential reject

Wiederholen Sie nach dem Löschen von Anmeldeinformationen den Klon- oder Pushvorgang. Git fordert Sie auf, erneut zu authentifizieren.

Wenn Sie eine Azure DevOps Server-Instanz klonen oder pushen, die ein selbstsigniertes oder internes CA-Zertifikat verwendet, schlägt Git mit:

fatal: unable to access '...': SSL certificate problem: unable to get local issuer certificate

Option 1: Verwenden von Windows SChannel (empfohlen unter Windows)

Konfigurieren Sie Git so, dass der Windows-Zertifikatspeicher anstelle des gebündelten OpenSSL-CA-Bundles verwendet wird. Wenn Windows dem Zertifikat oder der Zertifizierungsstelle Ihres Servers vertraut, sind keine weiteren Schritte erforderlich:

> git config --global http.sslBackend schannel

Weitere Informationen zum Konfigurieren des SSL-Back-End in Visual Studio finden Sie unter Git-Einstellungen – Kryptografienetzwerkanbieter.

Option 2: Konfigurieren Sie Git mit Ihrem CA-Zertifikat

Exportieren Sie Ihr Stamm- oder Zwischenzertifizierungsstellenzertifikat als Base-64-codierte .crt Datei, und teilen Sie Git mit, wo sie zu finden sind:

> git config --global http.sslCAInfo C:/Users/<yourname>/my-ca-cert.crt

Sie können das Zertifikat auch an das vorhandene Ca-Bundle von Git anfügen (in der Regel bei C:\Program Files\Git\mingw64\etc\ssl\certs\ca-bundle.crt), anstatt das gesamte Bundle außer Kraft zu setzen.

Informationen zu Pipeline-Agent-Szenarien mit selbstsignierten Zertifikaten finden Sie unter Ausführen eines selbst gehosteten Agents hinter einem Proxy oder mit selbstsignierten Zertifikaten.

Verwandte Inhalte

• Azure Repos Git-Dokumentation
• Klonen eines vorhandenen Git-Repositorys
• Speichern Sie Ihre Arbeit mit Commits
• Verwenden von Git-Verzweigungen