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.

En résumé

Cette première partie explique comment configurer et utiliser les branches dans GitLab pour un workflow collaboratif. Après avoir cloné un projet localement en HTTPS, on crée une nouvelle branche (dev1) pour y travailler, plutôt que directement sur la branche principale. Le transcript couvre la création, la navigation entre branches et l'importance de cette pratique pour éviter les erreurs sur le code partagé.

Points clés

  • Les développeurs clonent le projet en local avec git clone suivi de l'URL HTTPS, puis poussent leurs modifications au serveur GitLab
  • Créer une nouvelle branche (git branch nom) plutôt que travailler directement sur la branche principale est une meilleure pratique
  • Naviguer entre branches avec git checkout nom_branche - la branche active s'affiche en vert après git branch
  • La branche principale est partagée par tous les développeurs, donc un changement erroné y impacterait tout le pipeline CICD
  • Le workflow standard consiste à créer une branche, modifier le code, puis demander une fusion (merge request) après test et approbation du propriétaire

Questions fréquentes

Comment cloner un projet GitLab sur son système local?

Utilisez la commande git clone suivi de l'URL HTTPS du projet. Git extrait une copie complète de tous les fichiers et dossiers du référentiel local.

Pourquoi ne pas travailler directement sur la branche principale?

La branche principale est partagée par tous les développeurs. Un changement erroné y serait propagé à tous les processus suivants (tests, déploiement). On crée une nouvelle branche pour les modifications, qu'on teste avant fusion.

Comment naviguer d'une branche à une autre?

Utilisez la commande git checkout nom_branche pour passer à une branche différente. La branche active s'affiche en vert lors de l'exécution de git branch.