Pourquoi puis-je retirer une branche qui a été supprimée sur GitHub?

Dans notre référentiel GitHub, un collègue a supprimé une branche nommée release. Mais lorsque je lance git checkout releaselocalement, j'obtiens toujours la branche supprimée release. Idem, même lorsque j'ai extrait une autre branche, supprimé la releasebranche avec git branch -D releaseet exécuté à nouveau git checkout release.

Y a-t-il quelque chose à corriger sur le référentiel GitHub, ou dois-je réparer quelque chose localement?

Après avoir supprimé une branche du côté distant, vous pouvez toujours voir cette branche distante précédemment récupérée localement, voir:

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

Vous avez seulement supprimé la "version" mais pas les "télécommandes / origine / version". Supprimez-le comme ceci:

$ git branch -rd origin/release

Ou supprimez toutes les branches récupérées qui n'existent plus du côté distant:

$ git remote prune origin 

Lorsque les branches sont supprimées à distance, vous devez tailler votre référentiel local - la façon la plus simple de le faire est de

git fetch -p

Cela mettra à jour votre référentiel local avec toutes les modifications apportées au référentiel distant, mais sans mettre à jour aucune de vos succursales locales. Après avoir exécuté cela,

git branch --remote

n'affichera plus la branche distante supprimée.

les référentiels git sont complets, que ce soit sur votre propre système ou sur le serveur. Ainsi, lorsque vous clonez un référentiel pour la première fois, vous obtenez une copie complète et votre git local "connaît" toutes les branches distantes ainsi que vos branches locales. Ces informations ne sont pas synchronisées automatiquement, donc lorsque votre collègue a supprimé la releasebranche sur le serveur, votre référentiel git local n'a pas perdu sa notion de releasebranche distante . La synchronisation avec git fetchmet à jour toutes les informations locales sur les branches distantes afin qu'elles correspondent à l'état du serveur (à proprement parler, référentiel distant, où qu'il se trouve), mais sans supprimer aucune information locale sur les branches distantes. L'élagage avec git fetch -p(ou git fetch --prune, ou git remote prune) supprime les informations locales sur les branches distantes qui ont été supprimées.

Tim: Git est distribué VCS, donc lorsque vous clonez un dépôt à distance vers votre local, il clone tout (historique). Ainsi, lorsque vous avez cloné votre référentiel, il y avait une branche appelée release. Puisque votre collègue a supprimé la branche de publication à distance, jusqu'à ce que vous fassiez un élagage git fetch -pou supprimiez explicitement cette branche, votre section locale aura cette branche.

Peut-être un peu tangentiel mais la perspective de ce site pourrait aider à comprendre le sujet général de la suppression des branches:

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

Il y a un chevauchement avec certains de ce qui a déjà été discuté ici, mais l'accent est mis sur l'entretien ménager: supprimer les succursales, distantes et locales, qui ne sont plus nécessaires dans un environnement collaboratif. En particulier, la git branch --mergedcommande identifie les branches qui peuvent être supprimées en toute sécurité en raison de leur fusion avec votre ligne principale (ou la branche qui vous intéresse). Si vous collaborez, certains mini scripts plus sophistiqués comme celui-ci présenteront les choses dans un format agréable et digestible avec des dates et des auteurs.

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

(Malheureusement, "nice, digestible" ne s'applique pas au formatage des scripts eux-mêmes.)