2.6 Travail collaboratif

Dans le module précédent, vous avez travaillé seul sur un projet en utilisant git et GitHub. Vous avez commencé par créer une copie locale du projet, appelée clone. Ensuite, vous avez effectué des sauvegardes de vos fichiers au sein d’un dépôt, appelées commit. Pour finir, vous avez synchronisé votre dépôt local avec votre dépôt distant (sur GitHub) via un pull suivi d’un push.

Bien que GitHub et git permettent de travailler seul sur ses dépôts, ils sont conçus pour la collaboration. En tant qu’étudiant et futur scientifique, vous allez devoir collaborer abondamment à l’avenir. Il est donc indispensable de savoir utiliser des outils professionnels de collaboration.

La répartition réfléchie des différentes tâches d’un projet est un élément clé dans un travail collaboratif. Vous pourriez être tenté de diviser le travail via des échanges de mails ou encore via tout autre système de discussion instantanée, grand public ou professionnel. Le risque est de ne plus retrouver ces échanges. GitHub a la solution pour vous avec les issues. Ces dernières sont liées au dépôt sur lequel vous travaillez. Il est donc simple de retrouver les échanges importants sur un projet.

2.6.1 Issues

Une issue est une zone de discussion attachée à votre dépôt GitHub pour y discuter de questions techniques et scientifiques strictement en relation avec ce dépôt. Les issues sont accessibles dans l’entête des dépôts comme le montre l’image ci-dessous.

Rédiger correctement une issue nécessite une réflexion et prend du temps. Une question claire permet une réponse précise de la part des collaborateurs, ce qui représente un gain de temps important. Il ne s’agit pas d’un système de chat comme Discord ou Messenger… Vos “memes” et autres gifs animés pour exprimer vos émotions n’y ont pas leur place. De même, des échanges du genre : “tu es là ?”, “oui… tu travailles sur quoi ?”, “sur le premier graphique, mais sinon, je me cure les ongles, kiss kiss” n’ont absolument pas leur place dans les issues ! Vous avez un dépôt GitHub à disposition qui regroupe toutes les bonnes pratiques pour rédiger une issue : sdd_issues

La rédaction d’une question sous la forme d’une Issue se décompose en quatre étapes :

Choix d’un titre court qui résume la question
Rédaction de la question en respectant la syntaxe Markdown
Ajout de labels, de personnes assignées…
Soumission de l’issue via le bouton “Submit new issue”

Consultez le document suivant pour tout connaitre de la création d’une issue

Rappelez-vous qu’une issue doit être fermée lorsque le sujet de cette dernière a été débattu et le problème résolu. Ouvrez une issue différente pour chaque problème.

Pour accéder encore plus facilement aux issues dans vos projets de groupes, utilisez l’addins dédié :

GitHub met à votre disposition plusieurs outils pour améliorer l’efficacité d’un travail en équipe. Dans les issues vous pouvez ajouter des labels à vos questions par exemple. Il existe également dans la section Projects un outil de planification de projets, très utile, bien que nous ne l’utiliserons pas dans le cadre du cours.

2.6.2 Git

Git est un outil puissant, mais complexe. Dans le premier module, nous étions arrivés à la vision schématique suivante. (chaque boule bleue représente un commit soit une version enregistrée dans le système et les flèches indiquent d’où provient chaque version et où elle est utilisée ensuite) :

Ce gestionnaire Git peut être couplé à un hébergement sur le cloud, soit pour simplement faire un backup de nos projets, soit pour pouvoir échanger et collaborer. Nous utiliserons GitHub à cette fin dans le cours. Lorsque l’on travaille seul avec GitHub, l’évolution de notre projet ressemblera au schéma ci-dessous :

Représentation des versions successives d’un projet avec GitHub.

On réalise un envoi (push) lorsque l’on souhaite synchroniser nos changements locaux avec la version sur le “cloud”. Plusieurs commits peuvent être envoyés avec un seul push sur le réseau, et c’est d’ailleurs généralement comme cela que l’on procède. L’inverse (rapatrier localement les changements que d’autres collaborateurs ont envoyés sur la version réseau de notre projet) s’appelle faire un pull. Par conséquent, synchroniser complètement notre dépôt GitHub avec la version locale consiste à faire les trois actions dans l’ordre : d’abord un commit pour créer un nouveau point d’enregistrement de l’état du système et y inclure tous les fichiers qui ont été modifiés, ensuite faire un pull pour rapatrier localement les changements qui ont été réalisés par d’autres ou par GitHub lui-même, et enfin, faire un push pour envoyer nos propres modifications dans notre projet GitHub. Les autres utilisateurs feront aussi commit-pull-push de leur côté.

À vous de jouer !

Note : l’image suivante est interactive. Il vous est maintenant demandé de cliquer dessus pour indiquer quelles flèches représentent une action particulière dans le schéma présenté.

L’avantage principal de GitHub ne réside pas vraiment dans la possibilité de réaliser une sauvegarde en ligne, mais plutôt dans la possibilité de collaborer avec d’autres personnes présentes sur ce réseau comme l’illustre la figure ci-dessous. Deux scientifiques (les versions locales sur leurs ordinateurs respectifs sont indiquées en bleu pour l’un et en vert pour l’autre) collaborent sur un même projet que l’on appelle un dépôt (repository en anglais) lorsqu’il est en ligne. Le premier chercheur (boules bleues) initie le dépôt et réalise un push pour rendre son travail accessible sur le réseau (les versions GitHub sont représentées par des boules orange). Son collaborateur (boules vertes) clone ensuite le dépôt sur son ordinateur afin de pouvoir y travailler. Après avoir fait des changements, il réalise également un push sur le réseau. Le premier scientifique, avant de travailler à nouveau sur le projet, devra donc réaliser un pull pour obtenir en local l’ensemble des modifications fournies par son ou ses collaborateurs. Après ses propres modifications, il devra ensuite effectuer à nouveau un push.

À vous de jouer !

Pour être certain que vous ayez bien compris, encore une image interactive à cliquer…

À vous de jouer !

Effectuez maintenant les exercices du tutoriel A02Lc_git (Gestion de versions avec git).

BioDataScience1::run("A02Lc_git")

2.6.3 Gestion de conflit

Malgré la répartition des tâches, la collaboration entre plusieurs personnes sur un projet commun mène à des conflits. C’est-à-dire les mêmes parties de documents au sein d’un projet qui sont modifiées par deux membres du groupe. Ne redoutez pas les conflits (dans le contexte de GitHub, du moins). Leur gestion appropriée est une compétence que nous allons développer ici.

Prenons un cas concret entre des collaborateurs qui étudient deux populations de Paracentrotus lividus (Lamarck, 1816). Les collaborateurs sont oliviaMaes, arthurpeeters et GuyliannEngels. Le projet est disponible. Consultez-y par exemple les différents commits afin de suivre l’évolution du projet.

Arthur et Olivia ont édité la même section d’un document.

Que va-t-il se passer selon vous ? Lequel des deux collaborateurs va avoir le droit d’écraser le contenu de l’autre ? GitHub n’est pas capable de décider quelle version est la meilleure. Il va donc demander au dernier collaborateur qui souhaite ajouter ces modifications avec le suite d’instruction, commit -> pull -> push, de gérer ce conflit lui-même.

Cette animation montre l’importance de toujours bien lire le message renvoyé par git. Lors du pull, il précise qu’il y a un conflit à gérer dans le fichier urchin_notebook.qmd.

Vous pouvez ensuite vous rendre dans chaque fichier problématique pour retrouver la ou les zones de conflit (utiliser l’outil de recherche avec l’icône loupe dans l’éditeur RStudio et recherchez par exemple <<<<<). En fait, GitHub va placer les deux versions de la même section entre des balises spéciales pour vous permettre de les repérer : une série de signes “plus petit que” indique le début de la première version (<<<<<<<<<<<<<<<<<<<<<<<<). Ensuite, une série de signes “égaux” indique le passage à la seconde version (=======================). Enfin, une série de signes “plus grand que” indique la fin de la seconde version (>>>>>>>>>>>>>>>>>>>>>>>>). Un numéro de commit est aussi indiqué. Dans l’onglet “Git”, tous les fichiers qui ont des conflits non résolus apparaissent avec une petite icône orange marquée d’un “U”, pour “unresolved conflict”. Cela vous aide pour déterminer dans quel(s) fichier(s) se trouve(nt) le(s) conflit(s). Ouvrez chacun de ces fichiers. Ensuite, l’outil de recherche dans l’éditeur vous positionne au début du conflit. Notez bien qu’il peut y avoir plusieurs zones de conflit dans un même document. Répétez la recherche jusqu’à ce que RStudio vous dise qu’il ne trouve plus <<<<<. Éditez ces zones pour ne garder que la bonne version et éliminez les balises. Ensuite, sauvegardez le document et passez éventuellement au suivant.

La résolution d’un conflit se fait donc en éditant le fichier concerné. Vous devez choisir la partie qui vous semble la plus pertinente et effacer tout le reste, y compris les balises ajoutées par GitHub. Terminez l’opération en enregistrant votre fichier.

La gestion du conflit se termine par la réalisation d’un “commit” avec un message qui indique la résolution du ou des conflits, suivi par un “pull” pour vérifier qu’il n’y a plus de problèmes, et enfin un “push” qui synchronise votre version locale avec GitHub.

Votre ou vos collaborateurs doivent ensuite faire un “pull” de leur côté pour se synchroniser à leur tour. Nous vous conseillons à chaque fois que vous ouvrez un projet pour y contribuer de réaliser un pull afin de récupérer toutes les modifications réalisées par les autres membres du groupe.

Lorsque vous vous lancez dans un projet ou revenez vers lui, il faut toujours faire un “pull” avant de commencer à travailler pour vous assurer que votre copie locale du projet est bien synchronisée avec la dernière version en ligne sur GitHub. C’est d’autant plus important lorsque le dépôt a plusieurs collaborateurs, car il faut traiter immédiatement les conflits et ne surtout pas les laisser s’accumuler.

Lorsque vous avez terminé de travailler dans un projet. Il est conseillé de faire toujours un “commit”, suivi d’un “pull” en vérifiant bien si des modifications sont réalisées qu’il n’y a pas de conflits (sinon, on les règle directement comme expliqué plus haut) et enfin un “push”. Ne laissez jamais traîner un conflit ! C’est une situation transitoire normale de votre dépôt, mais qui nécessite une intervention rapide pour l’éliminer avant que d’autres “commits” ne viennent rendre la situation encore plus complexe.

À vous de jouer !

Complétez votre projet de groupe en y ajoutant des graphiques de distribution et en les interprétant.

Réalisez en groupe le travail A02Ga_analysis, partie I.

Travail en groupe de 4 pour les étudiants inscrits au cours de Science des Données Biologiques I : visualisation à l’UMONS à terminer avant le 2024-12-17 23:59:59.

Initiez votre projet GitHub Classroom

Voyez les explications dans le fichier README.md, partie I.