Artikelversion: Enterprise Server 2.17
Commit ist auf GitHub vorhanden, aber nicht in meinem lokalen Klon
Manchmal kann ein Commit auf GitHub Enterprise angezeigt werden, befindet sich aber nicht im lokalen Klon des Repositorys.
Wenn Sie mit git show einen bestimmten Commit in der Befehlszeile anzeigen möchten, kann ein schwerer Fehler auftreten.
Beispielsweise könnte lokal der Fehler bad object entstehen:
$ git show 1095ff3d0153115e75b7bca2c09e5136845b5592
> fatal: bad object 1095ff3d0153115e75b7bca2c09e5136845b5592Wenn Sie den Commit jedoch auf Ihre GitHub Enterprise Server-Instanz anzeigen, können Sie ihn ohne Probleme sehen:
github.com/$account/$repository/commit/1095ff3d0153115e75b7bca2c09e5136845b5592
Dafür sind mehrere Erklärungen möglich:
- Das lokale Repository ist veraltet.
- Der Branch, der den Commit enthält, wurde gelöscht, weshalb nicht mehr auf den Commit verwiesen wird.
- Jemand hat einen Push über den Commit erzwungen.
Das lokale Repository ist veraltet
Möglicherweise enthält Ihr lokales Repository den Commit noch nicht. Um Informationen vom Remote-Repository auf den lokalen Klon abzurufen, verwenden Sie den Befehl git fetch:
$ git fetch remoteDadurch werden die Informationen vom Remote-Repository sicher auf Ihren lokalen Klon kopiert, ohne die bereits ausgecheckten Dateien zu ändern. Mit git fetch upstream können Sie Informationen von einem geforkten Repository abrufen; mit git fetch origin Informationen von einem geklonten Repository.
Tipp: Weitere Informationen finden Sie unter „Remote-Repositorys verwalten und Daten abrufen“ im Pro Git-Buch.
Der Branch, der den Commit enthielt, wurde gelöscht
Wenn ein Mitarbeiter des Repositorys den Branch mit dem Commit gelöscht oder einen Push über den Branch erzwungen hat, ist der fehlende Commit möglicherweise verwaist (d. h., er kann über keinen Verweis mehr erreicht werden) und wird daher nicht in Ihren lokalen Klon abgerufen.
Wenn irgendein Mitarbeiter jedoch einen lokalen Klon des Repositorys mit dem fehlenden Commit besitzt, kann er ihn glücklicherweise zurück zu GitHub Enterprise pushen. Dabei muss er sicherstellen, dass von einem lokalen Branch auf den Commit verwiesen wird, und ihn dann als neuen Branch zu GitHub Enterprise pushen.
Nehmen wir an, diese Person hat noch einen lokalen Branch (nennen wir ihn B), der den Commit enthält. Dieser verfolgt vielleicht den Branch, dessen Push erzwungen oder der gelöscht wurde, und es wurde einfach noch keine Aktualisierung durchgeführt. Um den Commit zu bewahren, kann er diesen lokalen Branch zu einem neuen Branch (nennen wir ihn recover-B) auf GitHub Enterprise pushen. Für dieses Beispiel nehmen wir an, dass die Person ein Remote-Repository namens upstream besitzt, über das sie Push-Zugriff auf github.coom/$account/$repository hat.
Die andere Person führt Folgendes aus:
$ git branch recover-B B
# Erstellt einen neuen lokalen Branch mit Verweis auf den Commit
$ git push upstream B:recover-B
# Pusht den lokalen Branch B auf den neuen vorgelagerten Branch und erstellt dabei einen neuen Verweis auf den CommitJetzt können Sie Folgendes ausführen:
$ git fetch upstream recover-B
# Ruft den Commit in Ihr lokales Repository ab.Erzwungene Push-Vorgänge vermeiden
Vermeiden Sie erzwungenes Pushen zu einem Repository, sofern es nicht absolut notwendig ist. Dies gilt insbesondere, wenn mehrere Personen Pushes zum Repository durchführen können.