- Quand une migration est-elle nécessaire ?
- Points à vérifier avant la migration
- Créer un nouveau projet sur le serveur cible
- GitLab
- GitHub
- Transférer le dépôt Git vers le nouveau serveur Git
- 1. Vérifier si un ancien remote origin existe
- 2. Définir l’URL distante du nouveau projet
- 3. Transférer toutes les branches locales
- 4. Transférer les tags
- Tableau : différences entre les principales commandes git push
- Migration GitLab ou GitHub
- Différences entre GitHub et GitLab
- Aperçu des principales différences
- Quel système convient le mieux à chaque usage ?
- Différences lors de la migration
- Recommandations et bonnes pratiques
- FAQ
- Puis-je transférer les issues, merge requests ou contenus du wiki ?
- Que se passe-t-il si le projet cible contient déjà des fichiers ?
- Que deviennent les anciennes branches présentes sur le serveur mais absentes localement ?
- Dois-je renommer la branche master en main ?
Lorsqu’on souhaite transférer un dépôt Git existant vers un nouveau serveur Git, on se demande souvent comment effectuer techniquement la migration et quels points vérifier. C’est particulièrement vrai si l’ancien serveur n’est plus disponible ou accessible, par exemple lors du passage d’un serveur GitLab auto-hébergé à GitLab.com ou GitHub.
Dans cet article, je vous montre étape par étape comment effectuer la migration, quelles commandes Git utiliser et dans quels cas la procédure diffère. J’explique également les pièges courants, les alternatives et les réponses aux questions fréquentes.
Quand une migration est-elle nécessaire ?
Scénarios courants :
- L’ancien serveur Git n’est plus accessible.
- Il ne vous reste qu’un dépôt local sur votre ordinateur ou votre serveur.
- L’ancien serveur ne vous appartient plus, par exemple après un changement d’entreprise.
- Un projet doit être centralisé sur GitLab.com ou GitHub.
- Vous souhaitez regrouper plusieurs dépôts.
Dans ces situations, il est essentiel de savoir si vous disposez encore de toutes les anciennes données ou uniquement d’une copie locale correspondant au dernier clonage.
Points à vérifier avant la migration
Avant de migrer un dépôt Git, vérifiez les points suivants :
- Avez-vous encore accès à l’ancien serveur ?
Si oui, vous pouvez utilisergit push --mirrorafin de transférer réellement tout. - Disposez-vous uniquement d’une copie locale ?
Dans ce cas, seules les branches et les tags présents localement peuvent être transférés. - Des merge requests, issues, wikis ou pipelines ont-ils été utilisés ?
Ces données ne font pas partie du dépôt et ne peuvent pas être transférées avec Git. - GitLab et GitHub ne transfèrent que les données Git avec git push, keine Server-Metadaten.
Créer un nouveau projet sur le serveur cible
Que vous utilisiez GitLab ou GitHub, commencez par créer un nouveau projet vide.
GitLab
- Ouvrir le groupe
- « New project »
- « Create blank project »
- Désactiver l’option « Initialize repository with a README » pour effectuer une migration
(sinon un conflit de fusion apparaîtra lors du push)
GitHub
- Repositories
- « New »
- Choisir « Repository name »
- Ne créer ni README ni .gitignore
- Créer le dépôt
Transférer le dépôt Git vers le nouveau serveur Git
1. Vérifier si un ancien remote origin existe
git remote -v
2. Définir l’URL distante du nouveau projet
git remote set-url origin <NEUE-URL>
Exemple GitLab :
https://gitlab.com/benutzer/projekt.git
Exemple GitHub :
https://github.com/benutzer/projekt.git
3. Transférer toutes les branches locales
Si l’ancien serveur n’est plus accessible :
git push -u origin --all #alternativ kann auch git push --mirror origin verwendet werden
Cette commande transfère :
- toutes les branches locales
- y compris master ou main
- et configure le suivi pour les prochains pushs
4. Transférer les tags
Si le projet utilise des tags :
git push origin --tags
Tableau : différences entre les principales commandes git push
| Commande | Fonction | Recommandation |
|---|---|---|
git push --mirror origin | Copie toutes les branches, les tags, les paramètres distants et les références | À utiliser uniquement si l’ancien serveur est encore accessible |
git push -u origin --all | Transfère toutes les branches locales | Méthode standard pour une migration sans l’ancien serveur |
git push origin --tags | Transfère tous les tags | À exécuter après le push des branches |
git push -f origin | Force l’écrasement de la branche cible | Uniquement en cas de conflit avec un dépôt cible vide |
git remote set-url origin <URL> | Modifie l’adresse du remote | Étape principale de la migration |
Migration GitLab ou GitHub
| Sujet | GitLab | GitHub |
|---|---|---|
| Créer le projet sans README | Possible | Possible |
| Fonctions d’importation dans l’interface web | Très complètes | Complètes, mais moins que sur GitLab |
| Transfert des issues | Non, sauf via API ou exportations | Non |
| Commandes push identiques | Oui | Oui |
| Migration LFS | Pris en charge | Pris en charge |
En pratique, il n’existe pas de différence majeure, car les deux plateformes prennent Git en charge nativement. Les mêmes commandes permettent d’effectuer la migration.
Différences entre GitHub et GitLab
Même si GitHub et GitLab paraissent très similaires et fonctionnent tous deux parfaitement comme serveurs Git, certaines différences peuvent compter lors de la migration d’un dépôt ou pour le travail à long terme. Beaucoup de débutants se demandent si une migration vers GitHub diffère d’une migration vers GitLab ou si certaines fonctions manquent. Bonne nouvelle : les commandes Git sont identiques sur les deux plateformes, même si celles-ci diffèrent sensiblement dans plusieurs domaines.
Aperçu des principales différences
| Domaine | GitHub | GitLab |
|---|---|---|
| Orientation | Plus grande plateforme de développement au monde, fortement axée sur la communauté | Plateforme DevOps avec CI/CD et gestion de projet intégrés |
| Dépôts privés | Gratuits, mais avec des fonctions limitées | Gratuits avec de nombreuses fonctions, également pour les équipes |
| CI/CD | GitHub Actions, très flexible | GitLab CI/CD intégré nativement et étroitement lié |
| Structure des projets | Structure plate axée sur les dépôts | Structure élaborée de groupes et sous-groupes |
| Gestion des issues | Simple et claire | Plus complète avec tableaux, epics et feuilles de route |
| Wikis | Par dépôt | Par projet avec davantage de fonctions de gestion |
| Outils d’importation | Performants, mais moins complets que ceux de GitLab | Fonctions d’importation très complètes pour GitHub, Bitbucket, Jira, etc. |
| Auto-hébergement | GitHub Enterprise, coûteux | GitLab peut être entièrement auto-hébergé ; l’édition Community est gratuite |
| Gestion des droits | Simple | Très détaillée et fondée sur les rôles |
| Stockage gratuit | Limité pour LFS | Davantage d’espace gratuit pour les dépôts et le registre de conteneurs |
Quel système convient le mieux à chaque usage ?
GitHub est idéal si :
- vous lancez un projet open source
- vous souhaitez faire participer de nombreux développeurs externes
- vous recherchez une grande communauté et de nombreuses intégrations prêtes à l’emploi
- vous souhaitez utiliser GitHub Actions
GitLab est idéal si :
- vous recherchez une solution DevOps complète
- vous souhaitez organiser de nombreux projets dans des groupes
- vous avez besoin de l’auto-hébergement ou d’un contrôle total
- vous souhaitez utiliser CI/CD sans outils supplémentaires
Différences lors de la migration
Pour la migration proprement dite d’un dépôt Git, le choix entre GitHub et GitLab importe peu, car les deux respectent les mêmes standards Git. Les différences concernent surtout l’environnement :
- GitHub crée automatiquement la branche main, GitLab ne le fait qu’en option.
- Après le push, GitLab affiche automatiquement des indications pour créer des merge requests.
- GitHub privilégie les pull requests plutôt que les merge requests.
- GitLab prend en charge nativement les dépôts miroirs ; GitHub nécessite une automatisation ou des Actions.
- GitLab propose des assistants d’importation complets pour reprendre des projets GitHub avec leurs issues.
Recommandations et bonnes pratiques
- Projet public ou privé ? Définissez ce choix à l’avance dans le projet cible.
- Clé SSH ou HTTPS ? SSH évite de saisir constamment les mots de passe.
- Vérifiez les branches locales avant de les envoyer.
- Supprimez auparavant les anciennes branches devenues inutiles.
- Après le push, vérifiez que toutes les branches et tous les tags ont été transférés correctement.
FAQ
Puis-je transférer les issues, merge requests ou contenus du wiki ?
Non. Ces données se trouvent sur le serveur et non dans le dépôt Git. Leur migration nécessite des exportations ou des API.
Que se passe-t-il si le projet cible contient déjà des fichiers ?
Des conflits apparaîtront. Il est préférable de créer un projet cible entièrement vide.
Que deviennent les anciennes branches présentes sur le serveur mais absentes localement ?
Elles sont perdues si vous n’avez plus accès à l’ancien serveur.
Dois-je renommer la branche master en main ?
Non. GitLab et GitHub acceptent les deux noms.
Cet article a été traduit à l’aide de l’IA.