Lorsque vous travaillez avec le contrôle de version Git, il est souvent nécessaire de modifier l'historique de validation manuellement, même bien qu'il soit destiné à être immuable. Avec quelques commandes, vous pouvez recommencer à zéro et supprimer tout l'historique Git avant un certain point.
Pourquoi supprimer les anciens commits Git ?
Parfois, lorsque vous travaillez avec des référentiels Git, il peut être nécessaire de supprimer tout l'historique Git avant un certain commit. Ceci est généralement utile lorsque vous souhaitez repartir à neuf avec un historique frais. Tout le code restera le même, mais l'enregistrement de toutes ses modifications peut être supprimé sans problème.
Par exemple, supposons que vous ayez un très bon projet de site Web avec tout le passe-partout déjà configuré et que vous souhaitiez créer un autre site Web. Vous pouvez repartir de zéro ou utiliser le premier site Web comme modèle en le clonant, en supprimant toutes les pages et le code dont vous n'avez pas besoin, puis en le revalidant dans un nouveau référentiel. Cependant, cela vous laisserait avec un historique de commit désordonné, plein de toutes les modifications avant de le cloner. Ceci est utile pour les forks de référentiels, mais dans ce cas, il peut être supprimé.
La suppression d'anciens commits peut également être utile lorsque vous souhaitez supprimer des données sensibles qui peuvent avoir été commitées par inadvertance. Étant donné que l'historique Git est généralement immuable, vous ne pouvez pas supprimer complètement les secrets ou les jetons qui se sont retrouvés dans les journaux de commit en annulant le commit, vous devez le supprimer complètement.
Il est important de noter que la modification de l'historique Git, de quelque manière que ce soit, peut entraîner des problèmes lorsque d'autres membres de l'équipe se retrouvent avec un référentiel obsolète. L'historique Git est destiné à être immuable – les commits sont uniquement ajoutés, jamais soustraits. Si vous souhaitez supprimer un commit d'un référentiel GitHub partagé, vous devez soit le faire avant que les commits ne soient poussés, soit “forcer le push” pour écraser le contenu du référentiel. Si vous forcez le push, vous devrez demander à tous vos collaborateurs de recloner le référentiel.
Supprimer tous les commits avant un commit
< p>La première étape consiste à obtenir une référence à l'ID de validation que vous souhaitez cibler. C'est facile avec une application graphique ou via le site Web GitHub, où vous pouvez afficher directement le journal de validation. Sinon, vous pouvez utiliser la commande git log pour afficher une liste des commits.
git log
Ensuite, nous pouvons utiliser git checkout avec le drapeau spécial –orphan, qui ne vérifiera aucun historique de version avant le commit donné. Par exemple, supposons que nous souhaitions créer une copie du référentiel après le “passage à .NET 6,” nous pourrions copier l'ID SHA1 de ce commit et exécuter :
git checkout –orphan orphan-branch ee96691d2785da4bbbbb058382d41e0ccf2a7e7b
Cela laissera le référentiel dans un état où le HEAD extrait ne fait référence à aucun commit, ce qui peut en fait bloquer les clients de l'interface graphique Git comme GitKraken, illustré ici. Vous devrez préparer tous les fichiers et recommencer :
git add -A git commit -m “Truncated history”
Cela vous laissera une nouvelle “branche orpheline” sans référence aux commits avant l'historique tronqué.
Cependant, il n'a pas non plus de références aux commits après l'historique tronqué, et la branche master pointe toujours vers le mauvais emplacement. Pour les récupérer, nous devons rebaser la branche master sur la branche orpheline. Cela coupera essentiellement tous les commits après la cible du maître, les fera glisser au-dessus de la branche orpheline, puis mettra à jour le “maître” étiquette de branche pour pointer vers ce nouvel emplacement.
En utilisant le même ID de validation qu'auparavant, utilisez la commande suivante pour effectuer la rebase :
git rebase –onto orphan-branch ee96691d2785da4bbbbb058382d41e0ccf2a7e7b master
Vous devriez maintenant avoir un historique de validation approprié, où la branche principale est’ ;t faisant référence à d'anciens commits. Si vous êtes connecté à une télécommande, la “maître à distance” branch peut toujours afficher les anciens commits, mais ceux-ci disparaîtront une fois que vous aurez forcé le push.
La dernière chose à faire est de supprimer les anciennes données, de supprimer la branche orpheline temporaire et de nettoyer avec Git :
git branch -D orphan-branch git prune –progress git gc –aggressive
Une fois que& #8217;s fait, la seule chose à faire est d'ajouter une télécommande et de pousser vers le nouveau référentiel GitHub. Cependant, si vous tronquez l'historique dans un référentiel existant, vous devrez forcer push pour écraser l'historique :
git push –force
Et c'est tout. Vous avez rangé votre histoire ancienne pour garder les choses propres et organisées.
LIRE LA SUITE
- › Obtenez les dés Denary personnalisés de Curiosity Box dans la boîte d'automne
- › NotebookLM de Google change la donne pour la prise de notes
- › Les applications Microsoft 365 obtiennent une nouvelle police par défaut
- › Comment masquer et afficher des chansons sur Spotify
- &rsaquo ; Comment réparer “Le serveur de récupération n'a pas pu être contacté” Erreur Mac
- &rsaquo ; Windows 11 dit au revoir aux anciennes applications ARM