Le versionning ? Kézako ?

Comme son nom le laisse entendre ça sert à faire plusieurs versions d’un fichier ou d’un projet en général. EX : Un projet et en prod et on veut tester une évolution, donc on fera une version du projet avec l’évol développée. Cette version sera sur une autre branche.

Une branche ? tu m’a pris pour un jardinier ou quoi ??

Beh c’est un peu l’idée, prenons un pommier, son principe est tout bête : faire des pommes (ici des golden)

Il a un tronc qui soutient l’ensemble => c’est la branche master

Il a aussi des branches qui se ressemblent mais ne sont pas identiques => c’est ce qu’on appelle le workflow

Chaque branche a le même but => faire des pommes

Ok mais mon evol je la place où dans l’histoire ?

L’évol sera dans notre exemple une autre variété de pommes (des granny smith), pour ça je vais créer une branche pour cette evol tout bêtement appelé evol_granny_smith
Dans cette branche j’irai ajouter ma bouture pour qu’elle fasse les pommes que je souhaite.

Principe de fonctionnement

Le principe est simple il y a une branche master qui servira de base pour les autres branches.
La branche master sera et devra toujours être iso avec ce qui est en prod, ça nous servira de sauvegarde en cas de soucis.

Un projet en cours de développement sera fait sur la branche master, une fois le projet en prod il faut faire un workflow avec au minima une branche dev

La branche dev sera utilisée en quasi permanence par la suite et sera fusionnée sur la master une fois en prod et de nouveau utilisée.

Un peu de vocabulaire

• l’objet blob (pour binary large object désignant un ensemble de données brutes), qui représente le contenu d’un fichier
• l’objet tree (mot anglais signifiant arbre), qui décrit une arborescence de fichiers. Il est constitué d’une liste d’objets de type blobs et des informations qui leur sont associées, tel que le nom du fichier et les permissions. Il peut contenir récursivement d’autres trees pour représenter les sous-répertoires
• l’objet commit (résultat de l’opération du même nom signifiant « valider une transaction »), qui correspond à une arborescence de fichiers (tree) enrichie de métadonnées comme un message de description, le nom de l’auteur, etc. Il pointe également vers un ou plusieurs objets commit parents pour former un graphe d’historiques
• l’objet tag (étiquette) qui est une manière de nommer arbitrairement un commit spécifique pour l’identifier plus facilement. Il est en général utilisé pour marquer certains commits, par exemple par un numéro de version (qu’on se servira pour le composer)

Utilisation

Sur Bitbucket il faut tout d’abord créer un pojet dans lequel on ajoutera un dépôt (repository), c’est important de faire un projet sur Bitbucket par client ça permet de mieux les projets web et de les retrouver facilement. Pour rappel un client peut avoir plusieurs demande (site web, e-shop, appli mobile, …)

– Une fois le dépôt créé il faut le récupérer sur son ordi soit en ligne de commande ou depuis un logiciel comme SourceTree.
– Si c’est un site existant il faut copier l’intégralité des fichiers dans le répertoire que l’on vient de cloner et ensuite le pousser sur le dépôt distant généralement en message de commit ‘initial commit’.
– Si c’est un nouveau projet on peut directement commencer à bosser depuis ce dépôt.
– À chaque fin de tâche ou de fonctionnalité (idéalement) on pousse les fichiers sur lesquels on a travaillé sur le dépôt avec un message de commit assez explicite.

Utilisation du fichier .gitignore

Ce fichier sert pour ne pas versionner certains fichiers ou dossiers.
Mais on peut aussi ne pas versionner le contenu d’un dossier mais vouloir versionner un dossier spécifique qui se trouve dedans (le dossier plugins mais un plugins qui n’est plus maintenu) Exemple :

# ne versionne pas les dossiers
node_modules
/vendor
.idea

# Plugins
web/app/plugins
!web/app/plugins/mon_plugin_a_garder

Gérer les conflits

Il se peut que lorsqu’on travaille à plusieurs sur un projet il y ait des conflits (c-a-d qu’on a bosser sur le même fichier en même temps)
Malheureusement c’est le dernier qui poussera qui devra gérer les conflits.
Il faut prendre soin de comparer ce que le collègue a modifié et ce qu’on a modifié pour ne pas écraser le travail de l’autre.
Certain éditeur de code gèrent mieux que d’autres les conflits, sourcetree le fait mais il n’est pas adapté lorsqu’il y a beaucoup de fichiers en conflit, perso je préfère PhpStorm qui a une interface mieux pensée pour ça.

Quelques commandes

Les commandes permettent de gérér le flot de données et les niveaux d’enregistrement dans le système de contrôle de révision de Git, par exemple, le checkout et le pull permettent de récupérer les données; le commit de les envoyer.
Git dispose notamment des commandes suivantes :

• git init crée un nouveau dépôt
• git clone clone un dépôt distant
• git add ajoute de nouveaux objets blobs dans la base des objets pour chaque fichier modifié depuis le dernier commit. Les objets précédents restent inchangés
• git commit intègre la somme de contrôle d’un objet tree et les sommes de contrôle des objets commits parents pour créer un nouvel objet commit
• git branch liste les branches
• git merge fusionne une branche dans une autre
• git rebase déplace les commits de la branche courante devant les nouveaux commits d’une autre branche
• git log affiche la liste des commits effectués sur une branche
• git push publie les nouvelles révisions sur le remote. (La commande codend différents paramètres)
• git pull récupère les dernières modifications distantes du projet (depuis le Remote) et les fusionne dans la branche courante
• git stash stocke de côté un état non commité afin d’effectuer d’autres tâches
• git checkout annule les modifications effectuées, déplacement sur une référence (branche, hash)
• git switch changement de branche
• git remote gestion des remotes