10
votes

Autre moyen de faire une première poussée d'un grand repo

J'ai une application de rails largish 3.1 dans le développement et la production que je ne faisais que créer un environnement de mise en scène pour sur Heroku. Parce que mon repo git est assez grand, je reçois des erreurs de temps d'expiration d'environ 33% à chaque fois que j'essaie de pousser.

Y a-t-il une alternative à faire GIT Push Staling Master pour cette poussée géante initiale?

Le message d'erreur est xxx

////////////////////////////////// Solution / édition, plusieurs mois plus tard ...

Il y a une manière sournoise de résoudre ce problème, de nos jours, à l'aide de la fonctionnalité de pipeline (expérimentale) de Heroku, si vous avez déjà un environnement configuré dans lequel vous avez poussé le code. De l'héroku docs :

"Par exemple, vous pouvez pousser Code à la mise en scène, dites-la dans une limace et favorisez ensuite la limace de mise en scène à la production. "

prend environ 5 secondes pour Heroku pour appuyer sur la limace existante d'une application à une autre!


2 commentaires

Hé, pourriez-vous ajouter la nouvelle solution trouvée comme une réponse? Je ne peux pas encore implémenter. Merci!


Vous pouvez trouver la documentation simple sur la façon de procéder ici: devcenter.heroku.com/articles/labs -PiPelines - ça a fonctionné pour moi où toutes les autres réponses n'ont pas


4 Réponses :


0
votes

Non, le seul moyen d'obtenir du contenu sur Heroku est via une poussée git.

Hors de la curiosité Quelle est la taille de votre dossier de projet?


2 commentaires

La taille de la limace lorsque je déploie sur mon production Env est de 72 Mo. Sur ma machine locale, il est 560 Mo, mais cela inclut le SQLite3 dB et un tas d'autres trucs dans Gitignore et Slugignore. Merci pour la réponse - au moins je sais qu'il n'y a pas d'alternative facile.


Avez-vous beaucoup d'actifs statiques là-bas? Peut-être les accueillir sur S3 serait-il meilleur?



6
votes

L'alternative est de séparer votre géant s'engager dans de nombreuses petites. Tag ou branche avant de faire cela. Chacun aura un certain nombre de fichiers qui constituent une poussée raisonnable. Faites une branche TEMP pour pointer vers la pointe. Maintenant, réinitialisez le maître au premier de ces petits commits. Pousser. Définir le maître au prochain commit. Pousser. Répétez cette opération jusqu'à ce que fait.

Restaurez maintenant le maître à l'endroit où il était à l'origine. Vous avez déjà transféré les objets. En appuyant sur ce grand engagement ne devrait pas renvoyer tous les objets existants déjà à la télécommande.


4 commentaires

Cela semble extrêmement ennuyeux. Ta, cependant.


Ouais. Très hucky mais vous avez demandé une alternative;)


J'ai eu cette erreur avec un git: // repo à distance. J'ai changé en Git + SSH: // et ça a fonctionné bien. Ymmv ...


Vous pouvez éviter de changer de maître en couvrant les engagements en question et de créer des succursales. Vous pouvez ensuite pousser cette branche à maîtriser sur votre télécommande avec Git Push Origine Step1: maître .



8
votes

J'essayais de pousser des changements avec des vidéos et que vous avez:

git repack
git push 


0 commentaires

3
votes

Réponse de Adam, vous pouvez rompre votre gros pousscule contenant de nombreux engagements (et leurs blobs) dans de multiples pousses plus petites contenant chacun un sous-ensemble des engagements requis pour l'histoire de votre succursale.

Je l'ai déjà fait en cascant L'ensemble complet de commettre des blocs, utilisant des branches temporaires ou des balises, mais mes dernières tentatives utilisent le script en ligne ci-dessous. Je n'ai pas besoin de déplacer la tête ni de modifier l'index ou la copie de travail. P>

Vous devez d'abord vouloir décider à quel point vous serez agressif, vous serez en termes de nombre de commits pour chaque poussée - un plus grand nombre de Les engagements-périmés peuvent être légèrement plus rapides, mais le risque plus élevé de frapper le même problème. De plus, depuis que vos commits auront des tailles variées, certaines périodes de l'histoire peuvent contenir des engagements avec une taille supérieure à la moyenne. Certains blocs peuvent donc réussir alors que d'autres nécessitent une fractionnement ultérieure. Vous pouvez également constater que vous avez un commit unique qui ne peut pas être poussé, ce qui nécessite une solution différente. P>

Pour appuyer sur une nouvelle branche distante maître code>, exécuter p>

git push staging HEAD:master


0 commentaires