Course: La gestion de versions

Présentation

Pourquoi utilise-t-on la gestion de versions ?

Les systèmes de gestion de versions sont des outils largement utilisés dans le développement logiciel. Que ce soit sur un gros, ou un petit projet, avec un seul développeur ou des dizaines, le versioning est quasiment indispensable dans le processus de développement aujourd'hui. Mais à quoi cela peux bien servir ?

Le principal avantage du versioning, c'est que toutes les modifications que vous allez faire sur votre code vont être historisées. C'est à dire que vous pourrez réellement suivre étape par étape l'avancement d'un projet, ligne de code par ligne de code. Cela vous permet donc d'avancer de manière plus sécurisée, car les modifications que vous apporterai au code seront sauvegardées dans cet historique. Et par la même occasion, cela vous permet de revenir en arrière si il y a eu un problème.

Avec le versioning, on pourra facilement retrouver l'état de notre application à un moment "m" (état 1, état 2, état 3, etc...) :

Un autre point fort du versioning, c'est qu'il va vous permettre de fusionner intelligemment et automatiquement vos modifications avec celles d'autres contributeurs au projet (collègues, projet open-source,...). De part la création de branches, vous pourrez avoir différents état d'avancement de votre application, que vous pourrez fusionner au gré des besoins.

Par exemple :

un développeur peut travailler une semaine sur une fonctionnalité particulière
un autre développeur peut travailler à des petites corrections de bugs relevé dans le même logiciels

Avec le système de branches et de fusion (merge), le travail des deux développeurs pourra être rassembler dans une version supérieur, et on aura donc fusionner les petits correctifs d'un côté, avec la nouvelle fonctionnalité de l'autre.

Forum

Annonces Forum

Nommage des versions

Avant de rentrer dans le fond du sujet, il faut aborder la notion de nommage des versions logiciels. Il y a deux types de nommages de versions :

le nom commercial
le numéro de version technique

Par exemple, pour Windows, on est passé de Windows 3.1 à Windows 95, 98, windows 2000, windows Millenium, Vista, Seven, et maintenant Windows 10. Tout ces numéros de versions sont purement marketing. Un autre exemple avec Ubuntu : les versions ont le numéro de l'année et du mois auxquelles elles ont mise à disposition. Par exemple la dernière LTS (long term support) est la 18.04, car elle est sortie an avril 2018. Donc pour faire simple, il n'y a pas vraiment de règles pour le nommage marketing des versions, et un développeur doit en avoir conscience.

En revanche, il y a une convention en ce qui concerne les numéros de versions technique :

Donc quand on parle de Windows 10, c'est peut être la version 8.1.6 du logiciel qui est utilisé en réalité. Voici une page plus détaillée sur la notion de version logiciel : https://fr.wikipedia.org/wiki/Version_d%27un_logiciel

Git (CLI et GUI)

Il existe beaucoup de systèmes de gestion de versions, et ils offrent tous des avantages et des inconvénients. Le plus répandu aujourd'hui est GIT, créé par le fondateur de Linux lui-même (Linus Torvalds). Git offre ce que l'on appel une architecture décentralisée, et c'est un de ses points fort. Contrairement par exemple à SVN, qui lui offre une architecture centralisée. Même si la majorité écrasante des nouveaux projets se font sur Git, de nombreux acteurs utilisent aussi SVN ou d'autres logiciels de versionning encore aujourd'hui. Voici un lien vers un wiki référençant plusieurs logiciels de gestion de version : https://fr.wikipedia.org/wiki/Logiciel_de_gestion_de_versions

Voici un schéma très simpliste de la différence entre une architecture centralisée et décentralisée lorsque l'on parle de logiciel de versioning :

Pour apprendre le versioning dans ce cours, on se basera sur Git, car c'est un des systèmes de gestion de version les plus répandus aujourd’hui en développement web. Git est un logiciel qui fonctionne nativement en ligne de commande (CLI). Je vous encourage très fortement à connaitre les commandes Git au mieux, mais elles sont assez nombreuses, et l'idée n'est pas de vous faire retenir toutes ces commandes par coeur. De nombreux GUI existent qui vous facilite la vie. Nous utiliserons GitKraken dans ce cours. Vous trouverez sur ce lien un récapitulatif des principales commandes CLI de Git : https://github.github.com/training-kit/downloads/github-git-cheat-sheet.pdf. Téléchargez ce PDF, et gardez-le précieusement. Nous nous y référerons à toutes les étapes de ce cours, à chaque fois que nous utiliserons le GUI.

GitHub et consors

Github est une plateforme de partage collaboratifs de code source en ligne. C'est une sorte de réseau social pour développeur, ou tout le monde peu créé de nouveaux projets, collaborer sur des projets déjà existant, suivre des projets open-source, etc... Github est une plateforme en ligne, mais son système est construit autour de Git. Cela veux dire que vous allez pouvoir vous servir de Github comme repo officiel de votre code versionné sous Git.

Historiquement, Github est la plateforme de partage de code source. Mais elle a été racheté par Microsoft courant 2017/2018 (plusieurs milliards), et de nombreux développeurs ont fuit cette plateforme populaire à cause de ce rachat. D'autres plateformes ces ont alors démocratisées, telle que GitLab. GitHub reste toutefois une référence dans le milieu, et de nombreux contributeurs continue à l'utiliser encore aujourd’hui. C'est avec GitHub que nous travaillerons dans ce cours.

Un conseil : en tant que développeur, vous devez avoir un compte Github ou Gitlab, les recruteurs vous demanderons souvent ce genre de chose pour voir "ou vous en êtes".

Les dépôts locaux et distants

Les dépôts sont des emplacements qui vont contenir une copie du code source d'une application. Ils peuvent être hébergés à distance (par exemple sur un serveur Git sur Internet, tel que Github), ou bien en local, sur votre PC ou celui de vos collègues ou autres contributeurs au projet.

Dans le cas d'une architecture centralisée (tel que SVN), il y a un repo distant qui est le repository officiel, et des copies de travail. Dans ce cas, chaque développeur va envoyer ses modifications directement sur le repo distant et officiel.

Dans le cas de Git, il n'y a pas de repo officiel à proprement parlé. Tous les dépôts se valent, et le développeur va modifier son code dans son propre dépôt, en local. Il passera ensuite par une deuxième étape ou il enverra ses modifications aux repo distant officiel, car il faut bien un repo de référence.

Les dépôts distants (remote)

Le dépôt officiel est le point de référence de votre projet. Il contient la version la plus stable et la plus récente de votre code (généralement appelé "la branche master"). Sur Git, c'est un dépôt comme un autre à cause de l'architecture décentralisée. Mais certains réglages et workflow peuvent permettre de protéger ce dépôt afin qu'il ne soit modifiable que par une personne responsable du projet. Grâce à une plateforme comme Github, vous pouvez créer votre dépôt officiel sur un serveur Git déjà configuré, et accessible sur Internet. Mais normalement, vous devez installer Git sur votre propre serveur (voir aussi : gitlab, gitlab.com,...).

Le dépôt local

Votre dépôt local, c'est votre version de travail en cours sur un projet. C'est à dire que vous allez télécharger sur votre PC l'ensemble du code d'un projet à une version X depuis le dépôt officiel, vous allez y apporter des modifications (version Y), puis vous pourrez renvoyer vos modifications sur le dépôt officiel. C'est dans le dépôt local que vous allez faire vos modifications, qui pourront par la suite être fusionner avec le code présent dans le dépôt officiel.

Assignment

Création d'un premier dépôt local et d'un compte Github Assignment

Ajouter des fichiers au dépôt local

Ça y est, votre nouveau dépôt local tout frais existe. Mais il est vide... Aucun fichier n'est encore présent à l'intérieur. Lorsque l'on versionne les fichiers d'une application, la première étape à réaliser lorsque l'on rajoute des nouveaux fichiers est de les suivre (track, en anglais). Il va falloir dire à Git que ce nouveau fichier fait parti de ma nouvelle version, et qu'il faut surveiller toutes les modifications que je vais lui apporter.

Il y aura d'autres étapes à réaliser par la suite, que nous verrons au fur et à mesure. Ce schéma vous aidera à mieux comprendre les différents états de version d'un fichier :

Assignment

Tracker un fichier Assignment

Engager des modifications

Les commits sont la colonne vertébrale du versioning. Tous les systèmes de gestions de versions sont différents, mais ils proposent tous la gestion des commits. Un commit (de l'anglais "engager"), ça n'est ni plus ni moins qu'un aperçu de votre code à un instant "t". C'est comme une sauvegarde, mais au sens versioning du terme. Cela veux dire que ce que vous avez changé dans votre code n'est pas écrasé par vos modifs. L'ancien code est dans un ancien commit. Le nouveau code, dans un nouveau commit. Et vous pouvez très facilement naviguer de commit en commit, pour récupérer du code, voir ce que vous avez changé par rapport à des versions plus anciennes, etc...

Si par exemple vous corrigez un bug qui concerne le formatage d'une date dans une fonction, vous aurez un commit avant la correction (avec le bug), puis un commit après la correction (sans le bug). Et votre nouveau commit s'intitulera "Correction bug formatage date dans fonction xyz()".

Selon le système de gestion de versions que vous utiliserez, le fonctionnement d'un commit peut-être différent. Par exemple, sur SVN, un commit est envoyé automatiquement sur le dépôt officiel. En revanche, sur Git, un commit reste en local.

Nom et description d'un commit

Lorsque vous faites un nouveau commit, Git lui donnera automatiquement un identifiant. C'est une chaîne de caractère qui lui permettra de l'identifier parmi tous les autres commits présents dans votre historique de version. Donc cela se fait automatiquement, et vous n'avez pas vraiment en vous en soucier.

En revanche, lorsque vous faites des modifications dans votre code, vous devez impérativement détailler la modification que vous venez de faire. Ceci est très important, car cela va permettre de comprendre en un coup d’œil ce que vous avez voulu faire, et permettra aux autres développeurs, ou à vous même, d'y voir plus clair et de ne pas être obligé de lire le code pour savoir (en gros), ce que votre commit apporte.

Les commentaires sur Git

Voici des exemples de message de commit sur le github officiel du framework Bootstrap : https://github.com/twbs/bootstrap/commits/master

Assignment

Première version de la page d'accueil Assignment

Envoyer ou récupérer des modifications

Ces deux commandes sont très importantes dans Git car ce sont elles qui vont vous permettre de communiquer avec le dépôt officiel.

Pull

La commande pull (tirer) va vous permettre de récupérer une version présente sur le dépôt officiel. Elle est souvent utilisé sous cette forme : git pull origin master, ou origin désigne le chemin d'accès à votre dépôt distant (suivant votre config), et master désigne la branche que vous souhaitez récupérer. Il faut donc configurer "origin", et savoir quelle branche vous souhaitez récupérer.

Cette commande va récupérer tous les commits que vous n'avez pas en local, et va essayer de les fusionner à votre code actuel. Si les modifications sont compatibles, alors le système de gestion de versions va fusionner les modifications provenant du dépôt officiel avec votre code local. Si il y a un conflit sur une modif (par ex : deux développeurs ont modifié le même code), alors à ce moment, il vous faudra résoudre le conflit manuellement, et dire à Git ce qu'il doit faire. Nous verrons ça plus tard.

Push

La commande push (pousser) fait exactement l'inverse. C'est à dire qu'elle va envoyer tous vos nouveaux commits vers le dépôt officiel (via la commande git push origin master). Et de la même manière, il peux y avoir des conflits à gérer.

Note : avant de faire un push vers le dépôt officiel, vous devez être sur que vous avez la dernière version à jour dans votre dépôt local. Il faut donc régulièrement faire des git pull afin de s'assurer d'avoir un code récent en local, et que vos modifications ne vont pas interférer avec des commits qui auraient pu être ajouter entre temps.

Note : sur SVN, c'est la commande update qui joue à peu près le même rôle que pull.