Git prune

La sortie de git log affiche les 2 commits et les messages de commit correspondants concernant les modifications apportées à hello.txt.L'étape suivante consiste à rendre l'un des commits inaccessible.Pour ce faire, nous utiliserons la commande git reset. Nous réinitialisons l'état du dépôt sur le premier commit, « added hello.txt ».

Si maintenant nous utilisons git log pour examiner l'état du dépôt, nous pouvons voir que nous n'avons qu'un seul commit.

Le dépôt de démo est maintenant dans un état qui contient un commit détaché. Le deuxième commit que nous avons fait avec le message « added another line to hello.txt » n'est plus affiché dans la sortie de git log, mais il est maintenant détachéOn pourrait croire que nous avons perdu ou supprimé le commit, mais Git est très strict sur le fait de ne pas supprimer l'historique.Nous pouvons confirmer qu'il est toujours disponible, mais qu'il est détaché, en utilisant git checkout pour y accéder directement :

Lorsque nous faisons un check-out du commit détaché, Git est assez attentionné pour nous fournir un message détaillé expliquant que nous sommes dans un état détaché. Si nous examinons le journal, nous pouvons voir que le commit « added another line to hello.txt » est maintenant de retour dans la sortie du journal ! Maintenant que nous savons que le dépôt est dans un bon état de simulation avec un commit détaché, nous pouvons nous entraîner à utiliser git prune. Revenons tout d'abord à la branche main à l'aide de git checkout.

Lorsque vous revenez à la branche main via git checkout, Git est à nouveau suffisamment attentionné pour nous faire savoir que nous laissons un commit détaché derrière nous. Il est maintenant temps de nettoyer le commit détaché ! Nous allons exécuter git prune, mais nous devons tout d'abord nous assurer de lui passer quelques options. Les options --dry-run et --verbose permettent d'afficher une sortie indiquant le commit à nettoyer, mais elles ne le nettoient pas.

Cette commande renverra probablement une sortie vide. Une sortie vide implique que la commande prune ne supprimera rien. Pourquoi cela se produirait-il ? Eh bien, le commit n'est probablement pas complètement détaché. Quelque part, Git conserve toujours une référence à ce dernier. C'est un excellent exemple de la raison pour laquelle la commande git prune ne doit pas être utilisée de manière autonome en dehors de git gc. Il s'agit également d'un bon exemple qui démontre qu'il est difficile de perdre totalement des données avec Git.

Il est fort probable que Git stocke une référence à notre commit détaché dans le reflog. Nous pouvons enquêter en lançant git reflog. Vous devriez voir une sortie décrivant la séquence des actions que nous avons menées pour arriver à ce résultat. Pour plus d'informations sur git reflog, consultez la page git reflog. En plus de préserver l'historique dans le reflog, Git dispose de dates d'expiration internes pour déterminer quand il nettoiera les commits détachés. Encore une fois, il s'agit là d'informations d'implémentation que git gc gère, et la commande git prune ne devrait pas être utilisée de manière autonome.

Pour terminer notre démo de simulation de git prune, nous devons effacer le reflog.

La commande ci-dessus forcera l'expiration de toutes les entrées du reflog qui sont plus anciennes que maintenant. Il s'agit d'une commande brutale et dangereuse que vous ne devriez jamais avoir à lancer en tant qu'utilisateur occasionnel de Git. Nous exécutons cette commande pour démontrer la réussite de git prune. Une fois le reflog totalement effacé, nous pouvons maintenant exécuter git prune.

Cette commande doit afficher une liste de références d'objets Git SHA qui ressemble à la sortie ci-dessus.

La commande git prune propose une courte liste d'options que nous avons abordées dans la section de présentation.

N'exécutez pas la commande prune. Affichez uniquement une sortie indiquant ce qu'elle fera.

Affichez la sortie de tous les objets et de toutes les actions effectuées avec la commande prune.

Permet d'afficher la sortie qui indique la progression de la commande prune.

Permet de forcer l'expiration des objets qui ont dépassé la valeur de

La spécification d'un préservera toutes les options de cette réf head.

Les commandes git remote prune et git fetch --prune font la même chose : supprimer les réfs de branches qui n'existent pas sur le remote. Cela est hautement souhaitable lorsque vous travaillez dans un workflow d'équipe dans lequel les branches distantes sont supprimées après la fusion avec main. La deuxième commande, git fetch --prune, se connectera au remote et récupérera le dernier état du remote avant le nettoyage. Il s'agit essentiellement d'une combinaison de commandes :

La commande générique git prune est complètement différente. Comme indiqué dans la section de présentation, git prune supprimera les commits détachés localement.

La commande git fetch --prune est le meilleur utilitaire pour nettoyer les branches obsolètes. Elle se connectera à un dépôt distant partagé et récupérera toutes les réfs des branches distantes. Elle supprimera ensuite les réfs distantes qui ne sont plus utilisées sur le dépôt distant.

Non, git remote prune origin supprimera uniquement les réfs des branches distantes qui n'existent plus. Git stocke à la fois les réfs locales et distantes. Un dépôt comportera des collections de réfs local/origin et remote/origin. La commande git remote prune origin ne nettoiera que les réfs présentes dans remote/origin. Cela permet de laisser en toute sécurité le travail local dans local/origin.

La commande git prune est destinée à être invoquée en tant que commande enfant de git gc. Il est très peu probable que vous ayez un jour besoin d'invoquer git prune dans le cadre de vos activités quotidiennes d'ingénieur logiciel. D'autres commandes sont nécessaires pour comprendre les effets de git prune. Les commandes utilisées dans cet article sont git log, git reflog et git checkout.