Code et programmation

Versioning, travail collaboratif

Master Information-Communication Ecosystèmes médiatiques et transition numérique - ICP 2025

Objectifs

✅ Comprendre les concepts et le vocabulaire de la collaboration sur un projet de code
 

✅ Pouvoir dialoguer efficacement avec une équipe technique

 

✅ Suivre l'avancement du projet

Le problème :

Comment faire pour travailler à plusieurs sur la même base de code, sans écraser les modifications des collègues ?

Résultat final ?

<html>
+  <head>
+    <title>Mon Super Site</title>
+  </head>
  <body>
    <h1>Bienvenue</h1>
  </body>
</html>
index.html (Alice)
<html>
  <body>
    <h1>Bienvenue</h1>
  </body>
</html>
index.html
<html>
  <body>
    <h1>Bienvenue</h1>
+    <p>Ceci est mon premier site web.</p>
  </body>
</html>
index.html (Bob)
<html>
+  <head>
+    <title>Mon Super Site</title>
+  </head>
  <body>
    <h1>Bienvenue</h1>
  </body>
</html>
index.html (Alice)
<html>
  <body>
    <h1>Bienvenue</h1>
+    <p>Ceci est mon premier site web.</p>
  </body>
</html>
index.html (Bob)
<html>
  <head>
    <title>Mon Super Site</title>
  </head>
  <body>
    <h1>Bienvenue</h1>
    <p>Ceci est mon premier site web.</p>
  </body>
</html>
index.html (Fusionné)
<html>
  <head>
    <title>Mon Super Site</title>
  </head>
  <body>
    <h1>Bienvenue</h1>
    <p>Ceci est mon premier site web.</p>
  </body>
</html>
index.html
<html>
  <head>
    <title>Mon Super Site</title>
  </head>
  <body>
+    <h1>Bienvenue sur mon Super Site</h1>
    <p>Ceci est mon premier site web.</p>
  </body>
</html>
index.html (Alice)
<html>
  <head>
    <title>Mon Super Site</title>
  </head>
  <body>
+    <h1>Bienvenue à toi</h1>
    <p>Ceci est mon premier site web.</p>
  </body>
</html>
index.html (Bob)
<html>
  <head>
    <title>Mon Super Site</title>
  </head>
  <body>
+    <h1>Bienvenue sur mon Super Site</h1>
    <p>Ceci est mon premier site web.</p>
  </body>
</html>
index.html (Alice)
<html>
  <head>
    <title>Mon Super Site</title>
  </head>
  <body>
+    <h1>Bienvenue à toi</h1>
    <p>Ceci est mon premier site web.</p>
  </body>
</html>
index.html (Bob)

CONFLIT : plusieurs choix possible, obligation d'arbitrer :

  • Garder la version d'Alice ?
  • Garder la version de Bob ?
  • Fusionner les deux versions ?

???

Problèmes d'une gestion manuelle

  • Méthode de partage : FTP ? Clé USB ? Drive ?
  • Format de partage : archive (zip, tar.gz...)
  • Pas d'historique : qui a modifié quoi, quand et pourquoi ?
  • Ecrasement accidentel : oublis lors de la tentative de fusion manuelle

De nombreux problèmes se posent alors qu'il n'est question que d'un fichier et de deux développeurs. Sur un projet réel avec des centaines de fichiers et des dizaines de développeurs, on sent bien que cela va être très compliqué.

Les systèmes de contrôle de version (VCS) sont une réponse à  ces problèmes. Le plus utilisé est git.

git

Les commits

git permet de créer des sauvegardes de l'état du code à un instant T. Un peu comme on ferait une sauvegarde dans un jeu vidéo. On appelle ça un commit.

 

Chaque commit possède un identifiant, un message, un auteur et un lien vers le commit précédent.

 

Techniquement, un commit ne stocke que les modifications sur un fichier depuis le commit précédent.

L'historique

Le lien entre un commit et le commit qui le précède permet de former un historique.

Cet historique nous permet (entre autre) de :

  • Trouver le commit qui introduit un bug
  • Revenir à une version stable du code, antérieure à l'introduction de ce bug
  • Annuler un commit pour supprimer les changements qu'il a introduit

Les branches

git permet de créer des "univers parallèles". Chacun de ces univers est appelé une branche. Chaque branche a un nom. Il existe toujours au moins une branche dans un projet, dont le nom par défaut est main.

 

Généralement, la branche main contient le code stable déployé en production. Mais il existe toutefois des méthodes de travail différentes, ce n'est donc pas une vérité absolue.

 

Lorsqu'un développeur commence à travailler sur une nouvelle fonctionnalité ou sur la résolution d'un bug, il peut créer une nouvelle branche. Il peut faire évoluer le code en parallèle de la branche main. Cela lui permet de travailler de son côté, sans impacter le code stable. La branche pourra être fusionnée dans la branche main lorsque le travail sur celle-ci sera terminé.

Les branches

A partir de la branche main, on crée une branche feature pour pouvoir travailler sur une nouvelle fonctionnalité. On implémente la fonctionnalité, on crée 3 commits pour arriver au résultat souhaité.

Les branches

Une fois le travail terminé, on fusionne la branche feature avec la branche main, pour que notre nouvelle fonctionnalité fasse maintenant partie du code stable.

Les branches

Pendant que je travaille sur feature, le reste de l'équipe travaille en parallèle et fusionne ses changements sur main. Les deux branches avancent donc en parallèle. Ce sont deux "univers" où chacun contient une version différente du projet.

Les branches

Dans cette configuration, lorsque je fusionne feature dans main, un "commit de fusion" est créé pour symboliser cette fusion. Il peut arriver que mes collègues aient modifié les mêmes fichiers que moi. Dans ce cas, git est capable de fusionner les modifications automatiquement si elles ne concernent pas les mêmes lignes. Dans le cas contraire, il y aura un conflit qu'il me demandera d'arbitrer.

Collaborer

git est un VCS décentralisé. Cela signifie que chaque développeur possède l'ensemble de l'historique sur sa machine.

 

Il est possible de synchroniser l'historique des développeurs entre eux. Mais on a plutôt tendance à se synchroniser autour d'un historique "central". Pour ça, on utilise en général un service comme Github, qui offre une palette de fonctionnalités collaboratives et de gestion de projet.

Les Pull Requests (PR) permettent de collaborer autour de la fusion d'une branche vers une autre.

 

Lorsqu'un développeur pousse ses changements sur le dépôt central, il peut créer une PR. Celle-ci récapitule les modifications apportées, permet aux autres développeurs de faire une revue des modifications et de faire des suggestions, et permet la discussion autour de ces modifications.

 

Une fois que tout le monde est d'accord sur les modifications apportées, la PR peut être fusionnée. Dans le cas contraire, elle peut être fermée et abandonnée.

Pull Requests

Suivi de projet

Les Issues permettent de créer une discussion autour d'une nouvelle fonctionnalité ou d'un bug.

 

Elles peuvent être assignées à une ou plusieurs personnes, être associées à des labels, reliées à des projets pour obtenir une organisation sous forme de tableau Kanban.

 

Les PR et les commits peuvent aussi être reliées à une ou plusieurs issues. Cela permet de faire un lien entre les spécifications d'une fonctionnalité ou un rapport de bug et le code qui l'implémente.

Issues

Workflow classique

05 - Versioning

By Cyrille Perois

Made with Slides.com

05 - Versioning

  • 50

More from Cyrille Perois