Wenn du mit git show einen bestimmten Commit in der Befehlszeile anzeigen möchtest, kann ein schwerer Fehler auftreten.
Beispielsweise kannst du lokal einen bad object-Fehler erhalten:
$ git show 1095ff3d0153115e75b7bca2c09e5136845b5592
> fatal: bad object 1095ff3d0153115e75b7bca2c09e5136845b5592
Wenn du den Commit jedoch auf Ihre GitHub Enterprise Server-Instance anzeigst, kannst du 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 dein lokales Repository den Commit noch nicht. Um Informationen aus dem Remoterepository auf den lokalen Klon abzurufen, verwende den Befehl git fetch:
git fetch REMOTE
Dadurch werden Informationen aus dem Remoterepository sicher auf den lokalen Klon kopiert, ohne Änderungen an den Dateien vorzunehmen, die du ausgecheckt hast. Über git fetch upstream kannst du Informationen aus einem geforkten Repository abrufen. Du kannst auch git fetch origin verwenden, um Informationen aus einem Repository abzurufen, das du nur geklont hast.
Tip
Weitere Informationen zum managing remotes and fetching data findest du 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 durch einen erzwungenen Push überschrieben hat, ist der fehlende Commit möglicherweise verwaist (das heißt, er kann über keine Referenz mehr erreicht werden). Er wird daher nicht in deinen lokalen Klon abgerufen.
Wenn ein Mitarbeiter jedoch einen lokalen Klon des Repositorys mit dem fehlenden Commit besitzt, kann er ihn jedoch wieder zurück an GitHub Enterprise Server pushen. Dabei muss er sicherstellen, dass von einem lokalen Branch auf den Commit verwiesen wird, und ihn dann als neuen Branch an GitHub Enterprise Server pushen.
Nehmen wir an, die Person verfügt noch über einen lokalen Branch (nennen wir ihn B), der den Commit enthält. Dieser verfolgt vielleicht den Branch, der durch einen erzwungenen Push überschrieben oder gelöscht wurde, und es wurde einfach noch keine Aktualisierung durchgeführt. Um den Commit beizubehalten, kann die Person diesen lokalen Branch an einen neuen Branch (nennen wir ihn recover-B) auf GitHub Enterprise Server pushen. Gehen wir in diesem Beispiel davon aus, dass die Person über ein Remoterepository namens upstream verfügt, über das sie Pushzugriff auf github.com/ACCOUNT/REPOSITORY besitzt.
Die andere Person führt Folgendes aus:
$ git branch recover-B B
# Create a new local branch referencing the commit
$ git push upstream B:recover-B
# Push local B to new upstream branch, creating new reference to commit
Jetzt kannst du Folgendes ausführen:
$ git fetch upstream recover-B
# Fetch commit into your local repository.
Erzwungene Push-Vorgänge vermeiden
Vermeide erzwungenes Pushen zu einem Repository, sofern es nicht absolut notwendig ist. Dies gilt insbesondere, wenn mehrere Personen Pushes zum Repository durchführen können. Wenn jemand einen Push an ein Repository erzwingt, überschreibt der erzwungene Push möglicherweise Commits, auf denen die Arbeit anderer Projektmitarbeiter basiert. Erzwungene Pushes ändern den Repositoryverlauf und können Pull Requests beschädigen.