Nettoyage git et migration vers GitHub

Bonjour,

J’envisage de migrer quelques-uns de mes projets sur GitHub dans des repository privés. Pour le moment, ces projets sont hébergés sur un serveur privé loué chez une filiale d’OVH. J’aimerais les mettre sur GitHub pour plusieurs raisons:

• Ca fait des choses en moins à administrer sur le dit serveur et des potentiels risques de sécurité en moins
• Je n’aurai plus à me soucier des sauvegardes
• Le code sera sauvegardé ailleurs que chez OVH (j’ai échappé à la super incendie de Strasbourg, mais on ne sait jamais)
• C’est plus facile pour donner accès à d’éventuels futurs développeurs (pour l’instant je suis seul)
• Dans l’éventualité que d’autres développeurs se joignent aux projets, les outils fournis par GitHub pourrait être bien utiles

A cette occasion, je me demande s’il ne serait pas temps de faire du nettoyage. J’ai par ailleurs un peu peur de mal comprendre les limitations de GitHub gratuit.

Est-ce qu’il est possible de se débarrasser facilement de la majeure partie de l’historique des commits, pour ne garder que les dernières semaines ou les derniers mois par exemple ? Par ailleurs j’aimerais ne pas forcément envoyer toutes les branches, et que la branche XYZ devienne le nouveau master et me débarrasser de master en prime sans devoir faire de merge (il y a 2 ans de travail entre ma branche et master et je n’ai pas envie de m’amuser à gérer des conflits) ou même simplement la recharger.

Le répertoire git fait bientôt 500 Mo. IL y a des milliers de commits depuis 2009, dont une partie ont déjà été extraits d’un ancien SVN (utilisé jusqu’en 2015). Je me fiche pas mal de perdre tous les message de commit, ceux que j’écrivais à cette époque ne veulent pas dire grand chose, et ceux récupérés de SVN sont encore plus incompréhensibles et inutiles.

Comme mon compte GitHub est en mode gratuit et que mes repositories seront privés, est-ce que je ne vais pas me faire jeter parce que mes projets sont trop gros ? J’ai du mal à comprendre les limitations de GitHub. Est-ce que j’ai effectivement du souci à me faire ? Est-ce que je vais effectivement avoir du ménage à faire ? Ou bien est-ce que je cherche à couper les cheveux en quatre pour rien ?

En même temps je ne vois nulle part dans l’aide de GitHub des indications sur la taille limite d’un repository privé, ou le nombre de repository privés qu’on peut avoir. N’y a-t-il réellement aucune limite ? J’ai du mal à le croire.

Merci pour les éclaircissements que vous pourrez m’apporter.

Par ailleurs j’aimerais ne pas forcément envoyer toutes les branches, et que la branche XYZ devienne le nouveau master et me débarrasser de master en prime sans devoir faire de merge (il y a 2 ans de travail entre ma branche et master et je n’ai pas envie de m’amuser à gérer des conflits) ou même simplement la recharger.

Tu peux supprimer master puis renommer XYZ en master. Tu crées ton repo sur github, tu l’ajoutes en remote à ton repo local et tu ne pousses que les branches qui t’intéressent. (je n’ai pas la réponse pour l’historique)

En même temps je ne vois nulle part dans l’aide de GitHub des indications sur la taille limite d’un repository privé, ou le nombre de repository privés qu’on peut avoir. N’y a-t-il réellement aucune limite ?

La limite est de 500Mo par repository sur le plan gratuit (mais je ne sais pas comment ils "forcent/gèrent" ça), mais tu as un nombre illimité de repo => github pricing

Sinon tu as l’alternative GitLab (https://about.gitlab.com/pricing/) qui permet d’avoir des dépôts privés qui vont jusqu’à 10Go.

Avant que GitHub ne soit racheté par Microsoft, la grosse limitation du compte gratuit était de ne pas pouvoir avoir de repo privé. Il fallait un compte Pro à 7 $/mois. Mais depuis déjà un bon paquet de temps, ce n’est plus le cas et il est possible d’avoir autant de repos privés que tu veux avec un compte perso gratuit. Les comptes payants sont plutôt pour avoir des fonctionnalités typiquement utiles pour des organisations (et encore, j’ai un compte d’entreprise GitHub partagé avec quelqu’un sans que cela nous coûte le moindre centime).

Il n’y a pas de mention de limite de taille en ce qui concerne les objects de Git sur la page qui compare l’offre Free et les autres : https://github.com/pricing#compare-features

Est-ce qu’il est possible de se débarrasser facilement de la majeure partie de l’historique des commits, pour ne garder que les dernières semaines ou les derniers mois par exemple ? Par ailleurs j’aimerais ne pas forcément envoyer toutes les branches, et que la branche XYZ devienne le nouveau master et me débarrasser de master en prime sans devoir faire de merge (il y a 2 ans de travail entre ma branche et master et je n’ai pas envie de m’amuser à gérer des conflits) ou même simplement la recharger.

Je n’ai pas creusé le sujet plus que ça, mais ça me semble difficile au moins sur un point : chaque commit voit son hash calculé à partir de ce qui a précédé, et ainsi de suite. Si tu rognes une partie de l’historique, je ne vois pas comment Git peut s’y retrouver. Il existe peut-être des méthodes, mais dans ce cas je ne les connais pas.

Si c’est le .git qui devient gros, un git gc devrait le réduire (en local), mais au niveau de github je ne sais pas si les 500Mo le prennent en compte.

Je n’ai pas creusé le sujet plus que ça, mais ça me semble difficile au moins sur un point : chaque commit voit son hash calculé à partir de ce qui a précédé, et ainsi de suite. Si tu rognes une partie de l’historique, je ne vois pas comment Git peut s’y retrouver.

Tous les hashs qui suivent sont recalculés. C’est ce qui se passe avec git rebase qu’on pourrait appliquer sur les X premiers commits. Il faut prévoir un éditeur capable de faire des modifications en colonne, sinon ça va être long.

De ce que je comprends, les 500 Mo de GitHub concernent une fonctionnalité bien particulière de leur produit, GitHub Packages, sans que cela ne soit un problème pour le repo Git en tant que tel.

Il n’y a pas de limite de taille sur les dépôts Git sur GitHub, à l’exception de ce qui est manuellement stocké sur Git LFS. Il y a une soft-limit de 5 Gio chaudement recommandée de ne pas dépasser mais rien de bloquant. GitHub se réserve le droit de te contacter pour te demander gentiment de réduire un peu « if your repository excessively impacts our infrastructure », tout en indiquant être flexibles et compréhensifs (dans l’article sus-lié).

Il y a une soft-limit de 50 Mio par fichier et une hard-limit de 100 Mio par push (sauf import), cela dit (précisé dans le même article ci dessus).

Il n’y a pas moyen de squash les commits anciens et push les dernières semaines ?

C’est ce qui se passe avec git rebase qu’on pourrait appliquer sur les X premiers commits. Il faut prévoir un éditeur capable de faire des modifications en colonne, sinon ça va être long.

Ou plutôt faire ça automatiquement… Il suffit de créer une branche orpheline sur le nouveau commit qui doit être root, puis rebaser (pas interactivement !) sur ce nouveau commit. Par exemple pour ne garder que la dernière année d’historique, on peut procéder ainsi :

$ git log --before "1 year" -1 --oneline
<hash> Message
$ git tag new-first <hash>
$ git checkout --orphan orphan new-first
$ git commit -m "Root commit"
$ git rebase --onto=orphan new-first master
$ git tag -d new-first
$ git push --force-with-lease  # if already pushed somewhere

Évidemment, cette méthode est destructrice, à utiliser avec prudence.

EDIT:

Il n’y a pas moyen de squash les commits anciens et push les dernières semaines ?

Pas besoin de squasher des commits qu’on ne veut pas garder, les commits sont des snapshots entier (pas des diff!). Prendre le premier à garder comme le nouveau root-commit est suffisant.

Bonjour,

Si je comprends bien, la limite de 100 MO est par fichier individuel, et non pas sur le repository total. Du coup ça devrait être bon.

Les plus gros fichiers font dans les 3 ou 4 Mo. Je devrais quand même peut-être penser à les stocker ailleurs que sur git. Quelles bonnes solutions existent pour ça ? Dropbox & co, ou bien il y a mieux ? Question subsidiaire: comment font les développeurs de jeux vidéo pour stocker leur assets ?

Tous les hashs qui suivent sont recalculés. C’est ce qui se passe avec git rebase qu’on pourrait appliquer sur les X premiers commits. Il faut prévoir un éditeur capable de faire des modifications en colonne, sinon ça va être long.

N’y a-t-il pas un moyen de rebase ou de squash automatiquement les X premiers commits, ou tous les commits jusqu’à telle date ? Parce qu’évidemment sinon c’est assez pénible comme solution…. j’ai grosso-modo 1173 commits, calculé à la rache avec cette commande:

$ git log | grep "commit " | wc -l
1173

Merci pour vos réponses.

EDIT: le précédent post répond à ma question, j’avais pas vu. Merci.

Git LFS est conçu précisément pour ça. Je t’invite à te renseigner à son sujet GitHub a des offres LFS mais dans ces cas là, tu paies le stockage (1 Gio gratuit puis 5$/mois par paquet de 50 Gio ; incluant dans tous les cas autant de Gio par mois de bande passante).

Ça dépend de chacun, donc je ne saurais répondre précisément. On doit pouvoir trouver plus ou moins toutes les options en fonction des studios…

Bonjour,

IL y a quand même un truc que je ne comprends pas avec git LFS malgré ce que j’ai pu lire à ce sujet suite à vos interventions: qu’est-ce que ça change concrètement ?

Si je push un fichier binaire de 10 Mo, que je le modifie, que je le commit et le push à nouveau, ça fait 10 MO de plus, et ça fera 10 Mo de plus à chaque modification.

Que ce soit directement dans le repository git ou sur un serveur LFS prévu exprès pour ça, ça change quoi ? A quel moment on gagne de la place ?

S’il y a eu 10 modifications sur ce fichiers de 10 Mo, ça fait 100 MO d’occupés quelque part quoi qu’il arrive non ? Du coup le gain est totalement nul en espace disque ? OU bien il y a une subtilité de LFS qui permet de supprimer les trop vieilles versions dont on sait qu’on n’aura plus jamais besoin ?

Parce que si le "seul" bénéfice de LFS c’est la rapidité gagnée parce qu’on ne télécharge pas d’emblée toutes les versions de fichier, je n’ai pas encore atteint le point critique où ça devient intéressant, je pense.

Merci.