Gitlab - 3.1 Configuration de la branche Gitlab part 1

Maintenant que nous nous sommes familiarisés avec l'interface GitLab et que nous avons créé notre premier projet, il est temps d'apprendre à utiliser la fonctionnalité GitLab CI/CD et à écrire des pipelines pour dire à GitLab quoi faire. Dans un projet réel, les développeurs n'écrivent jamais leur code directement sur le serveur : ils l'écrivent localement sur leur poste, puis poussent le code vers le serveur quand une quantité significative est prête. C'est à ce moment-là que les processus de build, test et déploiement se déclenchent.

Cloner le projet en local

Pour récupérer le projet sur notre poste, nous le clonons via HTTPS. Sur le bureau, on ouvre un terminal, on installe Git, on crée un dossier dédié puis on lance la commande :

git clone https://gitlab.com/<user>/<repo>.git

Après authentification (nom d'utilisateur et mot de passe), le clonage récupère une copie complète des fichiers et dossiers du projet. À noter que le système d'exploitation a peu d'importance ici puisque l'environnement Cloud est principalement accessible depuis le navigateur — vous êtes libre de choisir Windows, macOS ou Linux. Pour ce cours toutefois, vous aurez besoin d'outils locaux comme Python, Docker ou un runner GitLab.

  • git clone <url> : cloner le dépôt en local
  • git branch : lister et vérifier la branche courante
  • git branch dev1 : créer une nouvelle branche
  • git checkout dev1 : basculer sur la branche dev1
  • ls : vérifier les fichiers présents

Une fois le projet ouvert localement, vérifions sur quelle branche nous nous trouvons avec git branch : par défaut, nous sommes sur la branche principale (main). Travailler directement dessus serait désastreux car c'est une branche partagée par toute l'équipe. Si du code défectueux y est poussé, tous les développeurs en hériteront. La bonne pratique est donc de créer une nouvelle branche pour chaque développeur ou chaque fonctionnalité, d'y faire ses modifications, puis de fusionner cette branche vers main via une merge request approuvée par un mainteneur.

Créons donc une branche dev1 avec git branch dev1, puis basculons dessus avec git checkout dev1. Un nouveau git branch confirme que dev1 est désormais la branche active (en vert). Un ls montre que les fichiers sont identiques à ceux de la branche principale au moment de la création. Nous sommes maintenant prêts à apporter des modifications dans la branche dev1 ; la suite arrive dans la prochaine vidéo.