Découvrez comment supprimer un fichier binaire volumineux de votre historique Git pour gérer la taille des dépôts clonés

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Git a gagné beaucoup de popularité ces dernières années en tant que référentiel de code source distribué qui permet aux utilisateurs de travailler avec le référentiel complet tout en étant déconnectés. Les avantages de Git sont bien documentés, mais que se passe-t-il si vous devez « restaurer l’horloge » sur le référentiel principal ? Cela n’est pas si intuitif et nécessite des autorisations élevées, car vous pouvez vous attendre à quelque chose qui affecte chaque utilisateur unique du référentiel.

Comment pouvez-vous restaurer le référentiel central en toute sécurité ?

Scénario du problème

Imaginez que vous validez un fichier volumineux, tel qu’une vidéo, sur votre serveur Git. Dans un système de code source traditionnel, il est pratique de stocker tout dans un seul endroit, puis d’extraire ce dont vous avez besoin. Toutefois, avec Git, l’ensemble du dépôt est cloné sur l’ordinateur local de chaque utilisateur. Avec un fichier volumineux, chaque utilisateur du projet doit également télécharger le ou les fichiers volumineux. Avec chaque fichier volumineux ultérieur validé sur le serveur, le problème augmente uniquement jusqu’à ce que le référentiel soit trop volumineux pour être efficace pour ses utilisateurs. Pour aggraver les choses, même si vous supprimez le délinquant de votre dépôt local et recommencez, le fichier existe toujours dans l’historique du dépôt, ce qui signifie qu’il sera toujours téléchargé sur l’ordinateur local de tout le monde dans le cadre de l’historique.

Ajout d’un fichier volumineux au référentiel local

Après avoir effectué la validation à partir du référentiel local, le serveur aura également le fichier volumineux

Figer le référentiel

Importante

Les étapes suivantes suppriment la vidéo de l’historique de votre branche, mais le fichier reste dans l’historique de votre dépôt lorsque vous clonez votre dépôt à partir d’Azure Repos. La suppression des fichiers de l’historique de votre branche empêche la mise à jour des fichiers, ce qui crée une autre version du fichier volumineux dans votre dépôt. En savoir plus sur la gestion des fichiers volumineux dans Git et consultez ce billet de blog pour obtenir une explication détaillée et une solution de contournement pour ce comportement lors de l’utilisation des dépôts Git Azure Repos.

Pour résoudre ce problème, vous devez commencer à la source, ce qui, dans ce cas, est le référentiel du serveur. Demandez à l’équipe d’arrêter l’envoi (push) vers le référentiel, mais si des push supplémentaires se produisent pendant ce processus, vous devrez également les prendre en compte, afin de ne pas perdre de données.

Rebaser et forcer l’envoi (push)

Si personne d’autre de l’équipe n’a apporté de modifications au référentiel , généralement par le biais d’un envoi (push), vous pouvez prendre l’itinéraire facile, dans lequel vous faites essentiellement de votre dépôt local la façon dont vous le souhaitez (c’est-à-dire, sans le fichier volumineux), puis forcer vos modifications sur le serveur.

Remarque : Vous devrez peut-être cloner ou corriger votre dépôt local avant de commencer ce travail. Cela peut entraîner une perte de travail ou des modifications, de sorte que continuer avec prudence.

Par défaut, vous avez probablement la possibilité de modifier leurs fichiers et référentiels de projet locaux et d’envoyer (push) vos modifications au serveur. Vous n’avez donc pas la possibilité d’apporter d’autres modifications, telles que des suppressions ou desbasages, au niveau du serveur. Par conséquent, vous devez acquérir des autorisations push Force de projet (par défaut) ou d’administrateur auprès de votre administrateur ou trouver quelqu’un qui les a et qui est prêt à vous aider. Pour plus d’informations sur les autorisations Git, accédez ici.

Ensuite, vous devez rebaser le référentiel.

1. Mais commencez git log par rechercher les valeurs de hachage SHA des validations les plus récentes. Vous aurez besoin de ces informations dans un instant. Cela est dû au fait que nous devons connaître la bonne validation la plus récente. Vous obtenez ces informations en ouvrant une invite de commandes Git et en tapant :

git log

Vous pouvez également obtenir le hachage SHA à partir de l’affichage de l’historique des branches dans Visual Studio Team Explorer.

2. Ouvrez maintenant une fenêtre de commandes Git.

3. Recherchez le nombre de hachage SHA qui vous intéresse.

4. Vous aurez besoin du sha qui commence par « 25b4 »

N'oubliez pas que git utilise des pointeurs pour déterminer où se trouvent la tête ou la branche actuelle dans le dépôt. En raison de cela, l’état du référentiel qui vous intéresse sera à un moment donné dans le passé. Pour « revenir en arrière dans le temps » et faire de cet état souhaité le nouvel état actuel, vous devez utiliser la commande git rebase :

git rebase -i <SHA hash of desired new current branch>

Le -i commutateur offre un peu de sécurité supplémentaire, car il affiche l’historique dans un éditeur (Mon implémentation de git sur la ligne de commande dans Windows affiche l’éditeur vi classique, que vous pouvez vous rappeler si vous avez travaillé avec un système Unix.)

5. Pour notre exemple, vous entrez :

git rebase -i 25b4

6. Une fois que l’éditeur s’affiche, supprimez toutes les lignes « Choisir » à l’exception de la branche que vous souhaitez conserver comme nouvelle tête. Lorsque tout ressemble à ce que vous le souhaitez, dans vi, tapez « :w<entrée> » pour enregistrer ou « !q<entrée> » pour quitter sans enregistrer.

Vous allez modifier la ou les lignes que vous ne souhaitez plus

7. Changez « pick » en « drop », puis tapez « :w » (dans vi) pour enregistrer et « :q! » pour démarrer le rebase.

Maintenant, tapez git log à nouveau : la branche incriminante doit être absente du journal. Si c’est le cas, vous êtes prêt pour l’étape finale, ce qui nécessite des autorisations d’administrateur de projet.

git log

Notez que la validation pour la vidéo volumineuse a maintenant disparu du dépôt local

8. Entrez : git push --force

Cette commande force votre dépôt à remplacer celui sur le serveur.

Utilisez avec précaution, car vous pouvez facilement perdre des données sur le serveur !!

Notez que vous devez vous authentifier auprès du serveur pour que cela fonctionne

Si vous utilisez Azure Repos, vous devrez peut-être configurer une autre information d’identification qui n’utilise pas de caractères spéciaux (par exemple, « @ » dans une adresse e-mail). Pour ce faire, suivez les instructions fournies ici.

À présent, la branche sera définitivement supprimée du serveur, et les clones et les synchronisations suivants par les membres de l’équipe de projet ne téléchargeront pas les fichiers volumineux que vous essayiez de supprimer. Les utilisateurs devront les extraire du serveur pour s’assurer qu’ils sont synchronisés avec le nouvel état du référentiel de serveur.

Si les utilisateurs ont des validations plus récentes

Si d’autres utilisateurs se sont déjà engagés dans le référentiel du serveur, vous devez tenir compte d’un élément supplémentaire. Vous souhaitez supprimer la branche qui contient le ou les fichiers volumineux, mais vous ne souhaitez pas perdre les modifications que l’équipe a apportées. Pour résoudre ce problème, lorsque vous ouvrez l’éditeur dans le cadre du rebasage, examinez attentivement les commits. Assurez-vous que les commits que vous souhaitez conserver sont répertoriés sur les lignes « pick » ; supprimez ceux que vous souhaitez retirer, comme lorsque un fichier volumineux a été ajouté.

Notez qu’après le rebasage, les autres utilisateurs de l’équipe doivent également rebaser afin que tout le monde dispose d’une copie cohérente du référentiel de serveur. C’est une douleur pour tout le monde et normalement devrait être évitée. Par conséquent, si vous avez besoin de supprimer un envoi comme indiqué ici, il est important de vous coordonner avec l’équipe. Pour plus d’informations sur le rebasage, consultez la documentation officielle sur le rebasage ici.

La clé consiste à vous assurer que vous savez quelles validations sont souhaitées et non souhaitées. Étudiez le journal Git ou l’historique de votre IDE (par exemple, Visual Studio) et faites une note soigneuse des hachages SHA à conserver et à éliminer.

Dans les scénarios où le fichier volumineux est présent depuis un certain temps et qu’il y a eu des branches et des fusions ultérieures, vous pouvez supprimer le fichier à l’aide du commutateur git filter-branch. Si vous souhaitez effectuer cette tentative, suivez les instructions ci-dessous.

Considérations relatives aux bonnes pratiques

Cela permet d'économiser beaucoup de travail pour s'assurer que les fichiers volumineux restent hors du référentiel principal dès le départ. Avec cela en tête, voici quelques bonnes pratiques de bon sens que l'équipe devrait garder à l'esprit :

Pratiques conseillées

• Effectuez fréquemment des modifications de validation. Vous pouvez toujours les corriger ultérieurement avec un squash ou un rebasage.
• Utilisez des branches pour isoler vos modifications. Les branches sont bon marché et privées, et la fusion est simple. Vous pouvez également sauvegarder les modifications sur une branche en le transmettant au serveur.
• Utilisez une convention d’affectation de noms lors de la publication de branches de rubriques. Nommez la branche «users/<alias>/<branchname> ». Cela permet de regrouper vos branches et de faciliter l’identification du « propriétaire ».
• N’oubliez pas de transmettre vos modifications. Commit != Checkin. (Commit + Push) == Checkin.
• Envisagez d’utiliser .gitignore pour les fichiers binaires volumineux afin qu’ils ne soient pas ajoutés au dépôt en premier lieu . plus d’informations ici.
• Envisagez d’utiliser le contrôle de version NuGet ou TFS pour stocker vos fichiers binaires volumineux.

Choses à ne pas faire

• Ne rebasez pas après l’envoi ( push). Le rebasage des commits poussés dans Git n'est pas recommandé, car il force les autres utilisateurs du dépôt à rebaser leurs modifications locales, ce qui pourrait les mécontenter s'ils doivent le faire. Le rebasage a envoyé des validations sur votre propre branche personnelle et, même si elles sont envoyées, ce n’est pas une transaction significative, sauf si d’autres personnes extraient ces validations.
• Ne validez pas les fichiers binaires dans votre référentiel. Git ne compresse pas les fichiers binaires comme le fait TFVC, et étant donné que tous les dépôts conservent tout l'historique, commettre des fichiers binaires signifie un embonpoint permanent.

Résumé

Parfois, des éléments indésirables, tels que des fichiers volumineux, sont ajoutés à un référentiel et doivent être supprimés pour conserver le référentiel propre et léger. Pour ce faire, vous pouvez obtenir votre référentiel local dans l’ordre à l’aide de la git rebase commande, puis en utilisant la git push --force commande pour remplacer le référentiel de serveurs avec votre référentiel local.

Auteurs : Edward Fry et Jesse Houwing | Se connecter avec les auteurs et ALM | DevOps Rangers ici

(c) 2015 Microsoft Corporation. Tous les droits réservés. Ce document est fourni «as-is». Les informations et les opinions exprimées dans ce document, y compris l'URL et d'autres références de site Web Internet, peuvent changer sans préavis. Vous acceptez le risque lié à leur utilisation.

Ce document ne vous fournit aucun droit juridique pour toute propriété intellectuelle dans n’importe quel produit Microsoft. Vous pouvez copier et utiliser ce document pour votre information uniquement.