Warum kann ich einen Zweig auschecken, der auf GitHub entfernt wurde?

In unserem GitHub-Repository hat ein Mitarbeiter einen Zweig mit dem Namen entfernt release. Aber wenn ich git checkout releaselokal laufe , bekomme ich immer den entfernten Zweig release. Das Gleiche gilt, auch wenn ich einen anderen Zweig ausgecheckt, den releaseZweig mit gelöscht git branch -D releaseund erneut ausgeführt habe git checkout release.

Gibt es etwas im GitHub-Repository zu reparieren, oder soll ich etwas lokal reparieren?

Nach dem Löschen eines Zweigs auf der Remote-Seite wird dieser zuvor abgerufene Zweig möglicherweise lokal angezeigt. Siehe:

$ git branch -a
[...]
release
remotes/origin/release
[...]

Sie haben nur die "Freigabe" entfernt, nicht jedoch "Fernbedienungen / Herkunft / Freigabe". Löschen Sie es wie folgt:

$ git branch -rd origin/release

Oder entfernen Sie alle abgerufenen Zweige, die auf der entfernten Seite nicht mehr existieren:

$ git remote prune origin 

Wenn Zweige aus der Ferne gelöscht werden, müssen Sie Ihr lokales Repository bereinigen. Am einfachsten ist dies mit

git fetch -p

Dadurch wird Ihr lokales Repository mit allen am Remote-Repository vorgenommenen Änderungen aktualisiert, ohne dass jedoch eine Ihrer lokalen Niederlassungen aktualisiert wird. Nachdem dies ausgeführt wurde,

git branch --remote

zeigt den gelöschten entfernten Zweig nicht mehr an.

Git-Repositorys sind vollständig, egal ob auf Ihrem eigenen System oder auf dem Server. Wenn Sie also zum ersten Mal ein Repository klonen, erhalten Sie eine vollständige Kopie, und Ihr lokaler Git „kennt“ alle Remote-Zweige sowie Ihre lokalen Zweige. Diese Informationen werden nicht automatisch synchronisiert. Als Ihr Kollege den releaseZweig auf dem Server löschte , verlor Ihr lokales Git-Repository nicht die Vorstellung eines entfernten releaseZweigs. Durch die Synchronisierung mit werden git fetchalle lokalen Informationen in Remotezweigen so aktualisiert, dass sie mit dem Status auf dem Server übereinstimmen (genau genommen, Remote-Repository, wo auch immer), ohne jedoch lokale Informationen in Remotezweigen zu löschen. Beim Bereinigen mit git fetch -p(oder git fetch --pruneoder git remote prune) werden die lokalen Informationen zu entfernten Zweigen entfernt, die gelöscht wurden.

Tim: Git ist ein verteiltes VCS. Wenn Sie also ein Repo von Remote auf Ihr lokales klonen, klont es alles (Verlauf). Als Sie also Ihr Repo geklont haben, gab es einen Zweig namens release. Da Ihr Kollege die Freigabe-Verzweigung remote git fetch -pgelöscht hat, wird Ihre lokale Verzweigung diese Verzweigung haben , bis Sie eine Bereinigung vornehmen oder diese Verzweigung explizit löschen.

Vielleicht ein bisschen tangential, aber die Perspektive dieser Site könnte helfen, das allgemeine Thema des Löschens von Zweigen zu verstehen:

http://railsware.com/blog/2014/08/11/git-housekeeping-tutorial-clean-up-outdated-branches-in-local-and-remote-repositories/

Es gibt Überschneidungen mit einigen der hier bereits besprochenen Themen, aber der Fokus liegt auf der Haushaltsführung: Löschen von Zweigstellen, die nicht mehr in einer kollaborativen Umgebung benötigt werden. Insbesondere git branch --mergedidentifiziert der Befehl Zweige, die sicher gelöscht werden können, weil sie mit Ihrer Hauptlinie (oder einem anderen Zweig, den Sie interessieren) zusammengeführt werden. Wenn Sie zusammenarbeiten, werden einige schicke Mini-Skripte wie dieses die Dinge in einem schönen, verdaulichen Format mit Datumsangaben und Autoren präsentieren.

for branch in `comm -12  <(git branch --merged|awk '{print($1)}') <(git branch -r --merged|awk '{print($1)}'|awk -F \/ '{print($2)}')`; do echo -e `git show --format="%ci %cr %an" $branch | head -n 1` \\t$branch; done | sort -r

(Leider bezieht sich "nett, verdaulich" nicht auf die Formatierung der Skripte selbst.)