Formation Collaboration DevOps avec GitLab et GitHub
Gérer dépôts, permissions, issues, merge et pull requests, et automatiser la CI/CD sur les deux forges de référence

- Durée
- 3 jours
- Niveau
- Fondamental
- Modalités
- Distanciel
Description de la formation GitLab GitHub

Objectifs pédagogiques
À l'issue de cette formation Collaboration DevOps avec GitLab et GitHub, vous aurez acquis les connaissances nécessaires pour :
- Gérer les dépôts, les utilisateurs et les permissions dans GitLab et GitHub.
- Implémenter des pipelines CI/CD avec GitLab CI et GitHub Actions.
- Utiliser les issues, les merge requests et pull requests ainsi que les tableaux de bord projets.
- Mettre en place des workflows de branches et de revue de code adaptés au travail en équipe.
- Comparer les deux plateformes pour choisir les pratiques adaptées à chaque contexte.
Objectifs opérationnels
Savoir exploiter GitLab et GitHub pour la gestion collaborative du code et l'automatisation DevOps.
Programme
Contenu du cours, module par module
12 modules
- Le versionnement distribué : dépôt local, dépôt distant, commits
- Branches, tags et fusion : les commandes indispensables
- Le rôle d'une forge : hébergement, collaboration, traçabilité, automatisation
- GitLab et GitHub : offres, hébergement SaaS ou auto-hébergé, positionnement
Travaux pratiques
Description :Chaque participant clone un dépôt, crée une branche, effectue plusieurs commits et pousse son travail. Il le pousse à la fois vers GitLab et vers GitHub. Il retrouve ensuite l'historique et les branches dans l'interface de chaque forge. Quelle différence fondamentale existe-t-il entre un dépôt local et un dépôt distant ? Un QCM rapide valide les acquis.
- Structurer l'espace : groupes, sous-groupes et projets GitLab face aux organisations et dépôts GitHub
- Visibilité des projets : public, interne et privé sur les deux forges
- Rôles et permissions : rôles de membres GitLab face aux rôles de dépôt et d'organisation GitHub, équipes GitHub
- Protéger le code : branches protégées GitLab face aux règles de protection et rulesets GitHub
- Templates de projets, README et accès par clés SSH et jetons
Travaux pratiques
Description :Les participants créent l'espace du projet fil rouge sous forme de groupe GitLab et d'organisation GitHub. Ils invitent leurs binômes avec des rôles différents et protègent la branche principale. Ils testent ensuite les actions autorisées ou refusées sur chaque plateforme. Quelles différences de gestion des droits faut-il anticiper lors d'une migration entre les deux forges ? Un tableau de correspondance des rôles complété en binôme sert de validation.
- Issues sur les deux forges : création, modèles, assignation, échéances
- Labels, types d'issues et champs de classification
- Hiérarchie du travail : epics, issues et tâches dans les work items GitLab, sous-issues dans GitHub
- Milestones et lien entre éléments de travail, commits et branches
Travaux pratiques
Description :À partir d'un besoin métier fourni, les participants rédigent les éléments de travail de l'itération. Ils les créent dans GitLab puis dans GitHub, avec leurs labels, leur hiérarchie et leur milestone. Ils comparent l'ergonomie et les possibilités de structuration de chaque outil. Quelle forge permet le mieux de décomposer une fonctionnalité en tâches ? Le formateur valide la cohérence des deux backlogs.
- Issue boards GitLab face à GitHub Projects : principes et vues
- Colonnes, filtres, champs personnalisés et vues feuille de route
- Automatisations du suivi : déplacement des cartes, fermeture automatique
- Releases et suivi de l'avancement d'une itération
Travaux pratiques
Description :Les participants construisent un tableau de bord GitLab et un projet GitHub reprenant le backlog. Ils paramètrent les colonnes d'avancement et une vue feuille de route. Ils font évoluer les cartes en simulant l'avancement de l'équipe. En quoi les deux outils rendent-ils différemment visibles les blocages ? Les deux tableaux de bord opérationnels servent de validation.
- Modèles de branches : GitLab Flow, GitHub Flow, GitFlow, trunk-based
- Contribuer par branche ou par fork : usages sur chaque forge
- Conventions de nommage, de commits et lien avec les éléments de travail
- Fichier CODEOWNERS et désignation des relecteurs sur les deux forges
Travaux pratiques
Description :Les binômes analysent trois contextes de projet et choisissent pour chacun un modèle de branches. Ils appliquent ensuite le modèle retenu sur le projet fil rouge, dans GitLab et dans GitHub. Un fichier CODEOWNERS désigne les relecteurs. Quel modèle de branches convient le mieux à une livraison continue ? La justification présentée au groupe sert de validation.
- Cycle de vie comparé d'une merge request GitLab et d'une pull request GitHub
- Revue de code : commentaires, suggestions, demandes de modification
- Approbations obligatoires et conditions de fusion
- Stratégies de fusion : merge, squash, rebase, et résolution des conflits
- Fermeture automatique des issues liées
Travaux pratiques
Description :Chaque binôme développe une fonctionnalité et ouvre une merge request dans GitLab puis une pull request dans GitHub. Le binôme voisin relit, commente et demande des modifications. Un conflit volontairement provoqué est résolu avant la fusion. Quels critères doivent être réunis avant d'accepter une fusion ? Les fusions conformes aux règles de protection et la fermeture des issues valident l'exercice.
- Fichier .gitlab-ci.yml face aux workflows du répertoire .github/workflows
- Stages et jobs GitLab face aux workflows, jobs et steps GitHub Actions
- Runners partagés, de groupe ou de projet face aux runners hébergés et auto-hébergés
- Déclencheurs : rules et workflow dans GitLab, événements « on » dans GitHub
- Lecture des logs et diagnostic d'échec
Travaux pratiques
Description :Les participants écrivent un pipeline de build et de tests pour le projet fil rouge, d'abord dans GitLab CI puis dans GitHub Actions. Ils le déclenchent sur un push et sur une demande de fusion. Ils analysent les logs d'exécution sur chaque forge. Quelles notions se correspondent directement entre les deux syntaxes ? Les deux pipelines exécutés avec succès valident l'exercice.
- Variables, variables protégées, secrets et GITHUB_TOKEN
- Cache des dépendances et artefacts : mécanismes comparés
- Enchaînement et parallélisation : dépendances entre jobs, matrices
- Réutilisation : include, templates et composants GitLab face aux actions et workflows réutilisables GitHub
Travaux pratiques
Description :Les participants ajoutent le cache des dépendances, la publication des artefacts et une matrice de versions. Ils externalisent une partie commune dans un template GitLab et dans un workflow réutilisable GitHub. Ils mesurent le gain de temps d'exécution obtenu. Pourquoi distinguer cache et artefacts dans un pipeline ? La comparaison des durées avant et après optimisation sert de validation.
- Tests automatisés et publication des rapports de tests
- Pipelines de merge request GitLab face aux status checks requis GitHub
- Bloquer la fusion d'un code dont les tests échouent
- Badges et visibilité de l'état du pipeline
Travaux pratiques
Description :Les participants rendent l'exécution des tests obligatoire avant toute fusion, dans GitLab et dans GitHub. Ils introduisent volontairement un test en échec et observent le blocage. Ils corrigent ensuite le code jusqu'à obtenir l'autorisation de fusion. Comment chaque forge empêche-t-elle la fusion d'un code défaillant ? La demande de fusion bloquée puis débloquée sert de validation.
- Analyse de qualité du code et intégration des résultats aux demandes de fusion
- Analyse des dépendances et des vulnérabilités : templates de sécurité GitLab, Dependabot et CodeQL côté GitHub
- Détection des secrets exposés dans le code
- Disponibilité des fonctions selon les offres de chaque éditeur
Travaux pratiques
Description :Les participants activent une analyse de dépendances et une analyse de code sur chaque forge. Ils introduisent une dépendance vulnérable et observent la remontée de l'alerte. Ils comparent la présentation des résultats dans GitLab et dans GitHub. Quelle forge rend l'information de sécurité la plus exploitable pour le développeur ? La correction de la vulnérabilité détectée valide l'exercice.
- Construire une image Docker dans un pipeline
- Container Registry GitLab face à GitHub Packages et au registre ghcr.io
- Publication de packages applicatifs sur chaque forge
- Versionnement, tags d'images et nettoyage des registres
Travaux pratiques
Description :Les participants automatisent la construction de l'image de l'application fil rouge dans GitLab CI et dans GitHub Actions. Ils la publient dans le registre de chaque forge avec un tag de version. Ils la récupèrent ensuite et la lancent localement. Comment garantir qu'une image publiée correspond exactement au code relu ? L'image versionnée et exécutée sert de validation.
- Environnements, historique des déploiements et retour arrière sur les deux forges
- Déploiement automatique en recette et approbation manuelle en production
- Secrets et variables par environnement
- Synthèse : critères de choix entre GitLab et GitHub selon le contexte
Travaux pratiques
Description :Les participants définissent des environnements de recette et de production sur chaque forge. Le déploiement en recette est automatique, celui en production soumis à approbation. Ils provoquent un déploiement défectueux puis effectuent un retour arrière. Quelle forge choisiriez-vous pour votre propre contexte, et pourquoi ? La grille comparative finale, complétée par chaque participant, clôture la formation.
Travaux pratiques
Projet fil rouge mené en parallèle sur une instance GitLab et une organisation GitHub de formation, avec Git et Docker. Environ 60 % du temps est consacré aux travaux pratiques.
Programme mis à jour le 09/11/2026
Public concerné
Développeurs, intégrateurs et ingénieurs R&D souhaitant collaborer et automatiser leurs livraisons avec GitLab et GitHub.

Prérequis
Des notions de développement logiciel ou de gestion de code source sont nécessaires. Elles permettent de comprendre les enjeux du versionnement, de la revue de code et de l'intégration continue abordés dès le premier jour. La maîtrise de Git n'est pas exigée : les commandes essentielles sont rappelées en début de formation.
J’évalue mes connaissances pour vérifier que je dispose des prérequis nécessaires pour profiter pleinement de cette formation en faisant le test de prérequis.
Faire le testFinancement
Cette formation peut être prise en charge par votre entreprise, seule ou avec l’appui de son opérateur de compétences. Nous fournissons le devis et les pièces attendues par l’OPCO.