Migrer de GitHub vers Codeberg : tuto complet pour garder le contrôle de son code

[nam1962]

Parce que votre code mérite un hébergeur qui respecte vos données.

J’avais tous mes dépôts sur GitHub depuis des années. Pratique, connu, efficace. Mais GitHub appartient à Microsoft, et la question de la souveraineté de nos données se pose de plus en plus. J’ai décidé de migrer vers Codeberg, une forge communautaire allemande, tout en gardant GitHub comme simple vitrine. Ce tutoriel vous montre comment j’ai fait, pas à pas, sans rien perdre.

---

• Pourquoi migrer ?
• La stratégie multi-forges
• Créer son compte et son organisation sur Codeberg
• Migrer ses dépôts (historique complet)
• Transformer GitHub en vitrine
• Archiver les dépôts GitHub
• Activer le 2FA GitHub avec KeePassXC
• Réorganiser ses dépôts locaux
• Bonus : GitLab comme preuve d’antériorité

---

Pourquoi quitter GitHub pour Codeberg ?

GitHub, c’est Microsoft (depuis octobre 2018, rachat pour 7,5 milliards de dollars). Vos dépôts, vos issues, vos contributions : tout est sur leurs serveurs, soumis au droit américain. Votre code a d’ailleurs servi à entraîner Copilot sans que personne vous demande votre avis.

Et depuis mars 2023, GitHub impose progressivement le 2FA à tous ses utilisateurs, par vagues. Ceux qui ne s’y soumettent pas se retrouvent en lecture seule : impossible de pousser du code, de créer des issues, de modifier quoi que ce soit. Votre propre code, sur votre propre compte, et vous n’y avez plus accès en écriture. C’est du chantage, ni plus ni moins.

Le problème n’est pas le 2FA en soi (c’est une bonne pratique de sécurité). Le problème, c’est que GitHub pousse ses utilisateurs vers GitHub Mobile ou Microsoft Authenticator, ce qui crée un lien avec votre smartphone et un vecteur de tracking supplémentaire. On verra plus bas comment contourner ça proprement avec KeePassXC : du TOTP généré localement, hors ligne, sans rien donner à personne.

Codeberg est une association loi 1901 allemande (eingetragener Verein), à but non lucratif. Elle est soumise au RGPD dans sa version la plus strictement appliquée. Pas de pub, pas de tracking, pas de monétisation de votre code.

Pour les Linuxiens que nous sommes, c’est cohérent : on utilise du logiciel libre, on peut aussi héberger notre code sur une forge libre.

La stratégie : ne pas mettre tous ses œufs dans le même panier

L’idée n’est pas de tout supprimer et de repartir de zéro. Voici la stratégie que j’ai adoptée :

• Codeberg : source de vérité, développement actif, issues, contributions
• GitHub : vitrine archivée avec un README qui redirige vers Codeberg
• GitLab (optionnel) : miroir dormant, preuve d’antériorité horodatée
• Forgejo self-hosted (plus tard) : pour les configs sensibles et les projets privés

Microsoft héberge gracieusement votre publicité pour Codeberg. Élégant, non ?

Créer son compte et son organisation sur Codeberg

Rendez-vous sur codeberg.org et créez votre compte. C’est gratuit, sans pub, sans tracking.

Si vous avez une organisation (un nom de projet, une association, un collectif), créez-la aussi : Paramètres > Organisations > Nouvelle organisation.

Ensuite, générez un token API (Settings > Applications > Generate Token). Cochez les permissions repository et organization. Notez le token, vous en aurez besoin pour la migration.

Important : supprimez ce token dès la migration terminée. Un token exposé, c’est un accès ouvert à vos dépôts.

Migrer ses dépôts sans rien perdre

On va utiliser git clone --bare puis git push --mirror. Ça préserve tout : historique, branches, tags.

1. Cloner en bare depuis GitHub

mkdir ~/migration && cd ~/migration
git clone --bare https://github.com/votre-user/votre-repo.git

2. Créer le dépôt vide sur Codeberg via l’API

Pour un dépôt personnel :

curl -X POST "https://codeberg.org/api/v1/user/repos" \
  -H "Authorization: token VOTRE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"votre-repo","private":false}'

Pour un dépôt dans une organisation :

curl -X POST "https://codeberg.org/api/v1/orgs/votre-orga/repos" \
  -H "Authorization: token VOTRE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"votre-repo","private":false}'

3. Pousser le miroir vers Codeberg

cd votre-repo.git
git push --mirror https://votre-user:VOTRE_TOKEN@codeberg.org/votre-orga/votre-repo.git

Et voilà ! Tout est là : commits, branches, tags. Vérifiez sur Codeberg que tout est en ordre.

4. Répétez pour chaque dépôt

Si vous avez plusieurs dépôts, vous pouvez scripter la chose. Voici un exemple pour une liste de dépôts :

TOKEN="votre_token"
REPOS="repo1 repo2 repo3"

for repo in $REPOS; do
  cd ~/migration
  git clone --bare "https://github.com/votre-user/$repo.git"
  
  # Créer le dépôt sur Codeberg
  curl -X POST "https://codeberg.org/api/v1/orgs/votre-orga/repos" \
    -H "Authorization: token $TOKEN" \
    -H "Content-Type: application/json" \
    -d "{\"name\":\"$repo\",\"private\":false}"
  
  # Pousser
  cd "$repo.git"
  git push --mirror "https://votre-user:$TOKEN@codeberg.org/votre-orga/$repo.git"
done

N’oubliez pas de supprimer le token immédiatement après !

Transformer GitHub en vitrine de redirection

Maintenant que le code est sur Codeberg, on va vider les dépôts GitHub et les remplacer par un simple README qui redirige les visiteurs.

cd /tmp
git clone https://github.com/votre-user/votre-repo.git gh-repo
cd gh-repo

# Supprimer tout sauf .git
find . -maxdepth 1 ! -name '.git' ! -name '.' -exec rm -rf {} +

# Créer le README de redirection
echo '# votre-repo

Ce dépôt est une archive. Le développement actif se fait sur Codeberg :

https://codeberg.org/votre-orga/votre-repo

Issues, contributions et code à jour sont sur Codeberg.' > README.md

git add -A
git commit -m "Migration vers Codeberg - ce dépôt est désormais une archive"
git push

cd /tmp && rm -rf gh-repo

Répétez pour chaque dépôt. Vous pouvez aussi scripter ça avec un tableau associatif qui mappe chaque repo GitHub vers son équivalent Codeberg (pratique si les chemins diffèrent).

Archiver les dépôts GitHub (la touche finale)

Pour un résultat vraiment propre, archivez les dépôts GitHub. Ça ajoute un bandeau jaune visible par tous : « This repository has been archived by the owner. It is now read-only. »

Si vous avez gh (le CLI GitHub) installé :

# Dépôts personnels
for repo in repo1 repo2 repo3; do
  gh repo archive votre-user/$repo --yes
done

# Dépôts d'organisation
for repo in repo4 repo5; do
  gh repo archive votre-orga/$repo --yes
done

Sinon, c’est dans Settings > Danger Zone > Archive this repository sur chaque dépôt.

C’est réversible à tout moment, ça n’efface rien.

Activer le 2FA GitHub via KeePassXC (sans app tierce)

Tant qu’on y est, sécurisons le compte GitHub. GitHub impose progressivement le 2FA à tous les comptes. Bonne nouvelle : pas besoin de Google Authenticator ou d’une app propriétaire. KeePassXC gère nativement le TOTP (si vous ne l’avez pas encore, suivez d’abord notre tuto KeePassXC).

1. Allez sur github.com/settings/security et cliquez Enable two-factor authentication
2. GitHub affiche un QR code. En dessous, cliquez sur setup key pour obtenir la clé en texte
3. Dans KeePassXC, clic droit sur votre entrée GitHub > TOTP > Configurer le TOTP
4. Collez la clé secrète, laissez les paramètres par défaut (RFC 6238), validez
5. Clic droit > TOTP > Copier le TOTP, collez le code dans GitHub pour confirmer
6. Sauvegardez les codes de récupération que GitHub vous fournit (dans une note sécurisée de KeePassXC)

Le TOTP est généré localement, hors ligne, par KeePassXC. Aucune donnée supplémentaire ne transite vers GitHub. Souveraineté jusqu’au bout.

Réorganiser ses dépôts locaux

Profitons-en pour mettre de l’ordre dans notre dossier ~/git. On repart de zéro en clonant depuis Codeberg (qui est maintenant notre source de vérité) :

# Renommer l'ancien dossier
mv ~/git ~/git-old

# Créer la nouvelle structure
mkdir -p ~/git/votre-user ~/git/votre-orga

# Cloner depuis Codeberg
cd ~/git/votre-user
git clone https://codeberg.org/votre-user/votre-repo-perso.git

cd ~/git/votre-orga
git clone https://codeberg.org/votre-orga/repo1.git
git clone https://codeberg.org/votre-orga/repo2.git
# etc.

# Nettoyer
rm -rf ~/git-old ~/migration

Structure propre, source de vérité unique, pas d’ambiguïté.

Bonus : garder GitLab comme preuve d’antériorité

Si vous avez un vieux compte GitLab avec des imports datant de plusieurs années, gardez-le ! C’est une preuve d’antériorité horodatée sur une plateforme tierce. En cas de litige ou de disparition d’une forge, c’est utile.

Quelques conseils :

• Passez les dépôts en public (si le groupe est privé, passez d’abord le groupe en public)
• Archivez-les via Settings > General > Advanced > Archive project
• Ne touchez pas au code : toute modification change la date de dernière activité
• Ajoutez dans votre bio GitLab une mention vers Codeberg

C’est un miroir dormant qui ne demande aucune maintenance.

---

---

Récapitulatif de la stratégie multi-forges

• Codeberg : développement actif, issues, contributions. Forge libre, RGPD, pas de tracking
• GitHub : vitrine archivée. README de redirection. Microsoft héberge votre pub pour Codeberg
• GitLab : miroir dormant. Preuve d’antériorité. Ne touchez à rien
• Forgejo self-hosted (optionnel) : configs serveur, dotfiles, projets privés. Souveraineté totale

Pour la suite (travailler au quotidien avec Codeberg, configurer SSH, ajouter une vitrine GitHub pour chaque nouveau projet), consultez le tuto compagnon : Travailler avec Codeberg au quotidien.

Adaptez cette stratégie à vos besoins. L’important c’est de ne pas dépendre d’une seule plateforme, surtout quand elle appartient à une entreprise dont le modèle économique n’est pas aligné avec le vôtre.

Made with soin, café, et sans Microsoft.

---

Notes

Pourquoi pas Framagit ? Framagit (l’instance GitLab de Framasoft) est une initiative sympa et pionnière, mais Framasoft a annoncé vouloir réduire la voilure sur ses services hébergés : l’instance est saturée et n’accepte plus les inscriptions ouvertes. Ce n’est pas un choix pérenne pour y migrer aujourd’hui.

Et le self-hosting ? Si vous voulez aller encore plus loin dans la souveraineté, vous pouvez installer votre propre forge. Forgejo est le choix que je recommande : c’est un fork communautaire de Gitea, léger, sous gouvernance associative (pas d’entreprise derrière). Il s’installe très facilement via YunoHost (en quelques clics) ou via Docker. C’est parfait pour versionner vos configs serveur, vos dotfiles et vos projets privés que vous ne mettrez sur aucune forge publique. On en reparlera dans un prochain tuto !

Un jeune site que j’aime bien, la ferrari du T-shirt …bio en plus : GoudronBlanc

Un jeune site que j'aime bien, la ferrari du T-shirt ...bio en plus : GoudronBlanc

[Auteur]

Articles