Versioning et gestion de code

--- title: Versioning et gestion de code tags: reboot, git, versionning robots: noindex, nofollow author: Julien Noyer --- # Versioning et gestion de code *Notions de base pour développeurs et dévelopeuses avisées* ![](https://i.imgur.com/hjiWxvS.png) > © [Julien Noyer](https://www.linkedin.com/in/julien-n-21219b28/) - All rights reserved for educational purposes only --- ## Introduction Le versioning est une méthode de gestion des versions d’un même produit (logiciel, base de données…).Il consiste à travailler directement sur le code source du projet, en gardant toutes les versions précédentes. Les outils du versioning aident les développeurs à travailler parallèlement sur différentes parties du projet et à revenir facilement aux étapes précédentes de leur travail en cas de besoin. L’utilisation d’un logiciel de versioning est devenue quasi-indispensable pour tout développeur, même s’il travaille seul. > En savoir plus https://bit.ly/3zbNL87 --- # Principes de base *Gérer un dossier de travail et les versions de code* ![](https://i.imgur.com/F3GYMWw.png) ## Installation de Git Avant de commencer à utiliser Git, il faut qu’il soit disponible sur votre ordinateur. Même s’il est déjà installé, c’est probablement une bonne idée d’utiliser la dernière version disponible. Vous pouvez l’installer soit comme paquet ou avec un installateur, soit en téléchargeant le code et en le compilant par vous-même. Voici les principales techniques d'installation de Git selon votre système d'eploitation : - **Windows** télécharger l'instaleur http://git-scm.com/download/win - **MacOS** télécharger l'instaleur http://git-scm.com/download/mac - **Linux** Taper la commande `sudo apt install git-all` > Retrouvez tous les détails concernant l'installation et l'utilisation Git sur le site officiel https://git-scm.com ## Initier un dossier Que vous souhaitiez créer un nouveau projet ou reprendre un répertoire distant, il vous est conseiller de suivre la même méthode. En règle générales, le principe proposé pour reprendre un répertoire est de le "cloner", nous l'aborderons plus tard dans ce document, mais cela peut entraîner dans certains cas des conflits. La méthode proposée ci-dessous s'adapte quant à elle à toutes les situations, libre à vous ensuite de choisir la méthode qui vous convient le mieux. La première étape de votre travail doit toujours être de créer un répertoire distant sur la plateforme de votre choix - [GitLab](https://gitlab.com) pour n'en citer qu'une - pour que dès l'initiation d'un projet, vous preniez l'habitude de le créer. Deux options s'offrent à vous lors de la création du répertoire, si vous en sélectionner une qui induit que le répertoire sera créé avec des fichiers initiaux, veillez à bien les récupérer lors de l'étape suivante. Une fois votre répertoire distant créé, vous devez en créer un local sur votre machine de travail, dans l'idéal avec le même nom pour simplifier son identification. Vous devez ensuite vous placer dans ce dossier avec votre invite de commande pour taper la commande suivante : ``` git init ``` > Cette commande permet d'instancier `git` dans votre répertoire Votre répertoire ainsi configuré, vous pouvez le connecter avec votre répertoire distant avec une commande spécifique qui permet de définir le répertoire distant comme `origin`. Cette commande doit être affichée sur votre plateforme - sauf si vous avez instancié votre répertoire distant avec des fichiers initiaux -, elle indique que votre `remote` (répertoire distant) est ajouté comme `origin` de la façon suivante : ``` git remote add origin ``` > Vous pouvez ajouter autant de `remote` en les nommant différemment > Pour récupérer des fichiers du `remote`, tapez la commande `git pull origin master` Si toutes ces étapes se sont déroulées sans accrocs, vous êtes prêt à démarrer un nouveau projet ! Mais avant ça, nous allons effectuer les premières actions nécessaires pour suivre les bonnes pratiques en terme de développement. ## Travailler sur des branches Lors de l'initiation de votre répertoire distant, une branche principale a été créée. Cette branche n'à qu'un seul objectif : contenir la version de code entièrement fonctionnelle. Du fait que vous débuter un projet, vous devez considérer qu'il est pour le moment entièrement fonctionnel, car vide de code, et commencer votre travail sur une nouvelle branche que nous allons appeler `dev`. Pour créer des branches, Git dispose de la commande `checkout` qu'il faut utiliser le la façons suivante : ``` git checkout -B dev ``` > Le drapeaux `-B` indique à Git qu'il faut créer une nouvelle branche > La commande `checkout` sans le drapeaux `-B` permet de changer de branche Dans la branche `dev` vous devez faire en sorte d'avoir du code prêt pour la production, c'est-à-dire qu'il doit pouvoir être testé. Vous pouvez débuter vos premières lignes de code sur cette branche, mais vous devez observer une logique dans l'utilisation des branches qui vous aidera à structures votre travail. Pour ne pas encombrer ce document avec trop d'information, il vous est conseillé de suivre les principes proposés par [**Daniel Kummer**](https://danielkummer.github.io/git-flow-cheatsheet/index.fr_FR.html) dans sa présentation de GitFlow sans pour autant installé GitFlow. ## Commit une version locale Alors que vous aurez fini une première étape dans votre code, vous allez vouloir le sauvegarder pour ne pas en perdre une ligne. Dans la terminologie de Git, cela s'appelle "faire un commit". Cette action permet de sauvegarder en local la version actuelle des fichiers et nous pouvons ensuite modifier les fichiers avant de faire un nouveau commit : nous aurons alors deux versions différentes des mêmes fichiers ce qui nous permet de conserver l’historique des modifications. Pour faire un `commit`, il faut suivre des étapes qui permettent d'ajouter les fichiers modifiés dans la zone de sauvegarde - le `stage` - puis de donner un nom à la sauvegarde. Ces deux commandes sont les suivantes : ``` git add . git commit -m "Description du commit" ``` > Pour votre premier `commit`, par convention sa description doit être `first commit` Une des consignes les plus importantes à respecter pour que votre travail soit le plus efficace, est de faire des `commit` régulièrement, voir très régulièrement. Pas si vous venez de créer un fichier `index.html` sans y avoir ajouté le contenu de base ou pour une simple modification de propriété CSS, mais quand vous venez de créer et de valider une nouvelle classe CSS, ou une fonction Javascript qui permet de capter un événement, il vaut mieux faire un `commit` pour rester l'esprit tranquille. ## Faire un "push" sur le répetoire distant Les différents `commit` que vous aurez fait sont stockés dans un répertoire nommé `.git` à la racine du répertoire principal de votre projet. Il sait d'une sauvegarde locale, en aucun cas votre `remote` n'a été mis à jour par les opérations précédentes. Pour mettre à jour votre `remote` avec Git, on dit qu'il faut "push" la ou les versions locales. De la même manière que pour les `commit`, vous devez respecter des consignes importantes pour ne pas risquer de perdre la moindre le ligne de code. Il en va de la logique : à quel moment pensez-vous qu'il est judicieux de faire une sauvegarde de votre travail ? Les plus exclusifs diront "en permanence", les plus raisonnable auront sans doute une approche différente. En terme de sauvegarde, dès qu'une étape importante de votre projet est passée, il faut "push" la branche locale, dès que vous pensez qu'un problème arrive sur votre machine de travail, il faut "push" la branche locale. Vous avez un doute ? Il faut "push" la branche locale. Pour envoyer toutes les dernières modifications que vous avez au préalable `commit` dans votre branche locale vers votre `remote`, vous devez taper la commande suivante : ``` git push origin ``` > Si votre `remote` ne s'appelle pas `origin` vous devez adapter le code ci-dessus > Pour `push` plusieurs branches vous devez répéter l'opération ## In case of emergency Pour récapituler et si vous ne devez vous souvenir que d'une chose : ``` git add . git commit -m "Description du commit" git push origin <NOM-DE-LA-BRANCHE> ``` > En savoir plus https://bit.ly/3cLfhAD --- # Git : commandes de base *Index des commande spécifique à Git* ![](https://i.imgur.com/K9oZkrL.png) ## Générales Git est un logiciel libre créé par Linus Torvalds, auteur du noyau Linux, et distribué selon les termes de la licence publique générale GNU version 2. Le principal contributeur actuel de git et depuis plus de 16 ans est Junio C Hamano. * Liste des commandes git : `git help` * Initier un projet git : `git init` * Voir la configuration : `git config —list` * Afficher la liste de commits (sur une ligne) : `git log —oneline` * Afficher les commits d’un fichier spécifique : `git log -p index.html` * Afficher les modifications apportées aux fichiers : `git diff` * Regarder l’état d’un commit : `git checkout 1234567` * Modifier un fichier dans un commit : `git checkout 1234567 index.html` * Défaire un commit : `git revert 1234567` * Défaire les modifications du commit d’un fichier spécifique : `git revert 1234567 index.html` * Revenir à un commit précis : `git revert 123456 (options —soft, —hard, —mixed)` ## Configuration d’un dossier La commande git config est une fonction pratique qui est utilisée pour définir les valeurs de configuration Git au niveau du projet global ou local. Ces niveaux de configuration correspondent aux fichiers texte .gitconfig. * Initialiser git : `git init` * Configurer l'email : `git config --global (ou --local) user.email «email@user.com»` * Configurer le nom : `git config --global (ou --local) user.name «nom»` * Configurer les couleurs des commande : `git config --global (ou --local) color.ui true` * Vérifier la config : `git config —list` * Voir l’état du dossier : `git status` ## Gestion des branches La branche par défaut dans Git s’appelle master., au fur et à mesure des validations, la branche master pointe vers le dernier des commits réalisés. À chaque validation, le pointeur de la branche master avance automatiquement. * Créer une branche : `git checkout -b nomDeLaBranche` * Voir la liste des branches : `git branch -a` * Travailler sur la branche : `git checkout nomDeLaBranche` * Envoyer les commits d’une branche dans le master : `git rebase master` * Ajouter les modification d’une branche dans le master : `git merge nomDeLaBranche` --- ## Ressources ![](https://i.imgur.com/eAySYs0.png) > Liste de liens utiles pour la mise en place de la séquence * **Site officiel Git** https://git-scm.com * **GitLab Cheat sheet** https://about.gitlab.com/images/press/git-cheat-sheet.pdf * **GitFlow** : https://bit.ly/2VHMwjh * **Site officiel Git** : https://git-scm.com/ * **Maîtriser Git en 28 minutes et 32 secondes** https://bit.ly/3CiDZCW * **Formation Git par Grafikart** : https://bit.ly/3AiEkoL