# Git au SSP --- ## Plan <!-- .slide: style="font-size: 80%;" --> 1. [Gestionnaire de versions](#1---Gestionnaire-de-versions) 2. [Dépot local & distant](#2---Dépot-Distant-) 3. [Les branches](#3---Les-branches--) 4. [Organisation au SSP](#4---Organisation-des-projets-dans-GitLab) --- ## 1 - Gestionnaire de versions ---- ### Qu'est ce que Git ? Git est un système de gestion de version : c'est à dire un **outil** qui va vous permettre de versionner votre code et de gérer les versions de votre code au fur et à mesure que vous le modifiez. ---- <!-- .slide: data-background="lightgrey" --> ![Versions](https://laurentc35.github.io/formation-git-sndil/images/commits.png) ---- <!-- .slide: style="font-size: 70%;" --> Il permet concrètement de : - revenir à une version antérieure :+1: - pour tout le code - ou seulement pour un fichier spécifique - gérer les différents environnements :+1: - développement - recette - production - partager ses modifications et de récupérer celles des autres :+1: - coder à plusieurs sur le même programme - donner un cadre pour travailler à plusieurs ---- ### Pourquoi utiliser Git ? Parce que vous ne supportez plus les fichiers _old_ et _new_ de vos collègues ? - modifications régulières du code - modifications qui peuvent apporter des bugs ⟹ il peut être difficile de se souvenir des dernières modifications et de retrouver ses repères dans le code quelques jours ou même quelques heures après --- ## 2 - GitLab : Dépot Distant :cloud: ---- GitLab est un site où sera stocké le code ainsi que l’historique de toutes les modifications. (Il est appelé un "_depôt_" ou _repository_ en anglais) ---- Chaque personne impliquée dans le projet modifie le code de son côté, et doit ensuite mettre à jour la version stockée sur GitLab, qui sert de version de référence. ---- <!-- .slide: data-background="lightgrey" --> ![Travaille à plusieurs Git](https://laurentc35.github.io/formation-git-sndil/images/depot-distant.png) ---- GitLab trace toutes les modifications apportées par les utilisateurs : - date de mise à jour - contenu de la modification - qui a modifié Cet historique complet permet de revenir aisément à une version antérieure. --- ## 3 - Les branches ! :deciduous_tree: ---- GitLab permet d'organiser le code en branches, c'est à dire: - le code est dupliqué en plusieurs versions - chaque version peut évoluer indépendamment les unes des autres - permet travailler chacun de son côté sur une branche différente Une fois qu'un utilisateur a fini de développer ce qu'il voulait faire, il va injecter ses modifications dans la branche principale. ---- <!-- .slide: data-background="lightgrey" --> ![Git branches](https://laurentc35.github.io/formation-git-sndil/images/gitflow.drawio.png) ---- ### Quand faire des branches ? ---- A la création du projet dans GitLab, on crée les branches principales de Recette et de Production, qui serviront à mettre le programme à disposition des utilisateurs ---- Quand une personne veut travailler sur le projet : - elle va créer une branche individuelle (dédiée au développement d'une fonctionnalité ou à la correction d'une anomalie) - une fois le développement fini la branche individuelle est injectée dans la branche principale et ne sera plus utilisée ---- Pour effectuer ces actions, on utilise des fonctionnalités Git, comme le commit, le pull, le push, ... Nous allons détailler certaines de ces fonctionnalités juste après. ---- ### Concrètement, ça donne quoi ? ---- #### Je veux corriger un bug ? ---- <!-- .slide: style="font-size: 70%;" --> - je récupère le code à jour depuis GitLab (Mots clé Git : _pull_) sur la branche principale (__developpement__ ou **recette**) - je crée une branche "**dev-{fonctionnalité/nomBug}**" à partir de celle de **developpement** (Mots clé Git : _checkout_) - je fais mes modifications dessus (je développe) - je valide mes modifications (Mots clé Git : _commit_) - je les pousse sur GitLab (Mots clé Git : _push_) - je propose mes modifications sur la branche principale (Mot clé : _Merge Request_) ---- #### Je veux mettre à jour la version de recette ? ---- <!-- .slide: style="font-size: 70%;" --> - je me positionne dans CERISE à l'endroit où je veux déployer/mettre à jour la version de recette - je récupère le code depuis GitLab (Mots clé Git : _clone_), ou je le mets à jour s'il est déjà présent (Mots clé Git : _pull_) - je récupère ou mets à jour le code depuis Gitlab (Mots clé Git : _clone_ (ou) _pull_) ---- - Les commandes élémentaires (_commit_, _pull_, _push_) peuvent être faites directement via l'interface Git proposée dans RStudio - Les autres commandes (comme lier un projet existant à GitLab, cloner un projet, créer des nouvelles branches individuelles, ...) peuvent être faites via un petit utilitaire en R développé par le BMIS (ou en ligne de commande... 🤓 ) --- ## 4 - Organisation des projets dans GitLab ---- Dans GitLab, vous arriverez dans le groupe ssp. Dans ce groupe, vous trouverez des sous-groupes pour chaque élément de l'espace de production de CERISE et pour chaque bureau. ---- ![Groupe SSP GitLab](https://laurentc35.github.io/formation-git-sndil/images/ssp_groupe.png) ---- Dans chaque sous-groupe, il est possible de créer d'autres sous-groupes pour suivre l'arborescence CERISE, et placer dedans les projets des programmes liés à un sous-groupe en particulier. ---- ![Groupe SSP GitLab x CERISE](https://laurentc35.github.io/formation-git-sndil/images/cerise_vs_gitlab.png) ---- Les sous-groupes des bureaux sont utilisés pour les programmes transverses (Rgonomie, SUIVAL, ...). --- ## Aide & soutien En cas de difficultés ou simplement pour demander des droits d'accès, n'hésitez pas à nous soliciter: - Via le [canal tchap](https://tchap.gouv.fr/#/room/#GitauSSPygKxJXVg3bf:agent.agriculture.tchap.gouv.fr) - Via la [bal BMIS](mailto:assist-stat.bmis.ssp.sg@agriculture.gouv.fr)
{"metaMigratedAt":"2023-06-17T08:43:55.715Z","metaMigratedFrom":"Content","title":"Git au SSP","breaks":true,"contributors":"[{\"id\":\"998a4349-3057-4892-bddb-a3f83e95adbd\",\"add\":6059,\"del\":1904},{\"id\":null,\"add\":2115,\"del\":290}]"}
    266 views