git remote prune - n'a pas montré autant de branches élaguées que prévu

113

Depuis la page de manuel:

Deletes all stale tracking branches under <name>.
These stale branches have already been removed from the remote repository
referenced by <name>, but are still locally available in "remotes/<name>".

J'ai donc supprimé un tas de branches en utilisant

git push origin :staleStuff

puis a couru

git remote prune origin

Cependant, une seule branche locale a été élaguée. Certaines de ces succursales ont été créées par moi, d'autres par des collègues. Cela indique-t-il que je n'ai pas suivi correctement ces succursales en premier lieu?

— Felixyz
source

pour savoir quelles branches vont être supprimées, vous pouvez faire git remote show originet rechercher toutes les branches marquéesstale

— Someone Somewhere

189

Lorsque vous utilisez git push origin :staleStuff, il supprime automatiquement origin/staleStuff, donc lorsque vous avez exécuté git remote prune origin, vous avez élagué une branche qui a été supprimée par quelqu'un d'autre. Il est plus probable que vos collègues doivent maintenant courir git prunepour se débarrasser des branches que vous avez supprimées.

Alors que fait exactement git remote prune? Idée principale: les branches locales (pas de suivi des branches) ne sont pas touchées par la git remote prunecommande et doivent être supprimées manuellement.

Maintenant, un exemple réel pour une meilleure compréhension:

Vous disposez d'un référentiel distant avec 2 branches: masteret feature. Supposons que vous travaillez sur les deux branches, donc vous avez ces références dans votre référentiel local (les noms de référence complets sont donnés pour éviter toute confusion):

refs/heads/master(nom court master)
refs/heads/feature(nom court feature)
refs/remotes/origin/master(nom court origin/master)
refs/remotes/origin/feature(nom court origin/feature)

Maintenant, un scénario typique:

Un autre développeur termine tout le travail sur le feature, le fusionne masteret supprime la featurebranche du référentiel distant.
Par défaut, lorsque vous faites git fetch(ou git pull), aucune référence n'est supprimée de votre référentiel local, vous avez donc toujours ces 4 références.
Vous décidez de les nettoyer et de courir git remote prune origin.
git détecte que la featurebranche n'existe plus, ainsi refs/remotes/origin/featurequ'une branche périmée qui doit être supprimée.
Maintenant, vous avez 3 références, y compris refs/heads/feature, car git remote prunene supprime aucune refs/heads/*référence.

Il est possible d'identifier les succursales locales, associées aux succursales de suivi à distance, par branch.<branch_name>.mergeparamètre de configuration. Ce paramètre n'est pas vraiment nécessaire pour que quoi que ce soit fonctionne (probablement sauf git pull), il peut donc manquer.

(mis à jour avec des exemples et des informations utiles à partir des commentaires)

— max
source

J'ai compris la situation: les branches sont toujours présentes localement mais retirées du dépôt distant. Maintenant, je veux supprimer toutes les branches locales qui n'existent pas sur la télécommande, donc je lance git prune. C'est ce que me dit «Ces branches périmées ont déjà été supprimées du référentiel distant». Ai-je tort?

— Felixyz

Vous avez raison, mais vous avez peut-être mal compris la signification de «succursales locales» dans le cas de git prune. Seules les branches en /refs/remotes/<remote_name>/sont soumises à la taille; aucune succursale /refs/heads/ne sera touchée - vous devez les gérer manuellement.

— max

Aha, c'est bien ce que je pensais. Il n'y a donc aucun moyen de faire ce que je veux: supprimer automatiquement toutes les branches dans les têtes qui suivent les branches distantes, en vérifiant si ces branches distantes sont supprimées?

— Felixyz

Il n'y a pas de commande intégrée pour cela, mais vous pouvez écrire un tel script vous-même. Les branches de suivi peuvent être identifiées par la présence du branch.<branch_name>.mergeparamètre de configuration.

— max

Cette réponse serait meilleure si vous ajoutiez les informations contenues dans les commentaires dans la réponse elle-même afin que tous ceux qui viennent ici et ont la même idée fausse que @Felixyz n'aient pas à regarder votre réponse de manière amusante, puis à lire les commentaires pour enfin comprendre. .

— Akrikos