On dirait que mon projet devient de plus en plus gros avec chaque git commit/push
. Existe-t-il un moyen de nettoyer mon dossier git?
On dirait que mon projet devient de plus en plus gros avec chaque git commit/push
. Existe-t-il un moyen de nettoyer mon dossier git?
Réponses:
Je ne sais pas ce que tu veux. Tout d'abord, bien sûr, chaque fois que vous validez / poussez le répertoire va devenir un peu plus gros, car il doit stocker chacun de ces commits supplémentaires.
Cependant, vous souhaitez probablement git gc
"nettoyer les fichiers inutiles et optimiser le référentiel local" ( page de manuel ).
Une autre commande éventuellement pertinente est celle git clean
qui supprimera les fichiers non suivis de votre arborescence ( page de manuel ).
WARNING
La commande comme écrite ci-dessus par @Kalle supprimera TOUS LES FICHIERS ET RÉPERTOIRES> NON SUIVIS < DANS VOTRE GIT ROOT , pas seulement "les fichiers répertoriés dans .gitignore". Tout ce qui n'est pas suivi par Git, qu'il soit répertorié ou non, .gitignore
sera effacé. git clean -dfX
(notez le cas sur le X
) supprimera uniquement les éléments qui ont une règle applicable dans .gitignore
. Veuillez tenir compte de cet avertissement: ne jamais exécuter git clean
sans l'exécuter en mode interactif, avec -i
au lieu de -f
, ou au moins faire un essai à sec d'abord - -n
puis à nouveau avec -f
.
Courir:
git remote prune origin
Supprime toutes les branches de suivi obsolètes qui ont déjà été supprimées origin
mais qui sont toujours disponibles localement dans remotes/origin
.
git gc --auto
' G arbage C ollection ' - exécute les tâches de maintenance (compresse les révisions, supprime les objets lâches / inaccessibles). L' --auto
indicateur détermine d'abord si un travail est nécessaire et se termine sans rien faire sinon.
Un scénario dans lequel votre dépôt git s'agrandira sérieusement avec chaque commit est celui où vous commettez des fichiers binaires que vous générez régulièrement. Leur stockage ne sera pas aussi efficace qu'un fichier texte .
Un autre est celui où vous avez un grand nombre de fichiers dans un dépôt (qui est une limite de git ) au lieu de plusieurs sous-dépôts ( gérés comme des sous-modules ).
Dans cet article sur git space , AlBlue mentionne:
Notez que Git (et Hg, et d'autres DVCS) souffrent d'un problème où les (gros) binaires sont archivés, puis supprimés, car ils apparaîtront toujours dans le référentiel et prendront de l'espace, même s'ils ne sont pas à jour .
Si vous avez de gros binaires stockés dans votre référentiel git, vous pouvez envisager:
git filter-branch
(avertissement: cela réécrira l'historique, ce qui est mauvais si vous avez déjà poussé votre dépôt et si d'autres en ont tiré)Comme je l'ai mentionné dans " Quelles sont les limites de fichiers dans Git (nombre et taille)? ", Le plus récent (2015, 5 ans après cette réponse) Git LFS de GitHub est un moyen de gérer ces gros fichiers (en les stockant en dehors du Dépôt Git).
oui oui, git gc
est la solution, naturellement,
et localement - vous pouvez simplement supprimer le référentiel local et le cloner à nouveau,
les secondes que vous attendez pour que cet énorme git & externals traite soient collectées à de longues minutes dans lesquelles sont collectées à des heures de temps inefficace passé,
Créez un nouveau référentiel (entièrement, pas seulement une branche) à partir de zéro , y compris la seule version récente des fichiers, naturellement vous perdrez toute l'histoire,
mais quand dans le monde du code, il n'est pas temps de devenir sentimental, il ne sert à rien de faire glisser les 5 années entières de code à chaque commit ou diff, vous pouvez toujours stocker les anciens git & externals quelque part, si vous êtes nostalgique:]
mais, à un moment donné, vous devez vraiment avancer:]
votre équipe vous remerciera!
Exécuter cette commande est extrêmement dangereux, mais réduira votre référentiel en effaçant tous vos fichiers de récupération / sauvegarde git:
git reflog expire --expire=now --all && git gc --prune=now --aggressive
Cela effacera tous les fichiers que git utilise pour récupérer votre référentiel à partir d'une mauvaise commande, par exemple, si vous l'avez fait git reset --hard
, vous pouvez généralement récupérer les fichiers perdus. Mais si vous le faites git reset --hard
avant la git reflog expire...
commande, vous avez tout perdu. Maintenant, votre seul espoir est d'utiliser un outil qui analyse votre système de fichiers et d'essayer de récupérer les fichiers effacés, s'ils n'ont pas été remplacés.
git clean -d -f -i
est la meilleure façon de le faire.
Cela aidera à nettoyer de manière plus contrôlée.
-i
signifie interactif.
git clean
n'est pas tant pour nettoyer le repo que pour nettoyer le répertoire. Pour les utilisateurs qui copient / collent aveuglément, méfiez-vous; cela supprime les fichiers / répertoires non suivis que vous pourriez souhaiter localement.
Je ne sais pas si cela le réduira, mais après avoir couru git clean
, je le fais souvent git repack -ad
aussi, ce qui réduit le nombre de fichiers du pack.
git gc
processus, donc pas besoin de l'exécuter séparément