GitLab → GitHub Contributions Sync
janvier 2026 → janvier 20263 min de lecture
Au travail, tout mon code part sur le GitLab de l’entreprise. Résultat, rien de tout ce travail n’apparaissait sur GitHub, alors que c’est le profil que les gens regardent.
Alors j’ai fait un petit script qui va chercher mes commits sur GitLab et les reporte sur un dépôt GitHub à part, chacun à sa date. Le premier soir, plus de deux ans et demi de commits sont remontés d’un coup sur mon graphe. C’est un script Bun en TypeScript, et le code est sur GitHub.
Rien ne sort de l’entreprise
Le code appartient à mon employeur, donc rien de l’entreprise ne doit sortir. Le script ne clone aucun dépôt. Il interroge l’API de GitLab avec un jeton en lecture seule, et ne demande que la liste des commits. Pour chacun des miens, il crée sur le dépôt GitHub un commit vide, à la même date, avec toujours le même message, « Work activity ». Le code, le titre, l’empreinte et le nom du projet restent dans l’entreprise.
C’est le point sur lequel j’ai le plus insisté après coup. La première version, faite en une soirée en janvier, reprenait dans chaque commit le nom du projet et le titre d’origine, avec l’empreinte du commit dans un fichier à côté. Il n’y avait pas de code, mais le nom d’un projet et le titre d’un commit en disent déjà long sur ce que fait une entreprise. En juillet, j’ai tout enlevé pour ne garder que la date.
Comment ça marche
Je n’ai aucune liste de projets à tenir à jour. Le script demande à GitLab tous les projets dont je suis membre, page par page, donc un nouveau dépôt est pris en compte tout seul à la synchro suivante. Dans chaque projet, il parcourt les commits de toutes les branches et ne garde que ceux de mon adresse mail, pour ne pas reporter ceux des collègues. Les projets sont interrogés cinq à la fois, pour aller plus vite sans surcharger le GitLab.
Chaque commit GitHub reprend la date du commit d’origine. Sans ça, tout tomberait le jour de la synchro et le graphe ne voudrait plus rien dire. La partie Git passe par simple-git, qui crée les commits du plus ancien au plus récent, puis pousse tout d’un coup à la fin. Pour que GitHub les compte, l’adresse mail des commits doit être vérifiée sur le compte. Le dépôt, lui, peut rester privé, à condition d’afficher les contributions privées sur son profil.
Le GitLab de l’entreprise n’est pas sur gitlab.com et a son propre certificat. L’adresse du GitLab se règle donc dans la config, et une option coupe la vérification du certificat.
Ne traiter que le nouveau
Le script retient les commits déjà reportés, par leur empreinte, dans un fichier qui reste à côté de lui et ne part jamais sur GitHub. À chaque lancement, il ne traite que les nouveaux, donc on peut le relancer autant qu’on veut sans créer de doublon. La liste est aussi sauvegardée en cours de route, pas seulement à la fin. Si le script est coupé, il ne repart pas de zéro.
Aujourd’hui
Je n’y pense plus. CronLab, mon planificateur de tâches pour Windows, le lance tous les soirs et me prévient s’il échoue. Et le code n’a plus bougé depuis juillet.