3.5 Travail collaboratif

Si GitHub permet de travailler seul sur ses dépôts, il est prévu pour collaborer. En tant que scientifique, vous êtes amené à collaborer abondamment à l’avenir.

3.5.1 Ajout d’un collaborateur

Partons directement d’un cas pratique entre deux chercheurs. Marie prend contact avec Guyliann afin de collaborer sur un projet lié à la biométrie humaine. Guyliann accepte volontiers de l’aider. Cependant, Marie doit lui donner accès à son dépôt. Pour cela, elle se rend dans sur son dépôt, puis va dans Settings puis Manage access et enfin, ajoute un collaborateur en cliquant sur Invite a collaborator.

Guyliann reçoit un mail afin d’accepter ou non de collaborer. S’il l’accepte, il obtient alors des droits en écriture sur le dépôt de Marie, ce qui lui permettra de réaliser des pushs. Il peut maintenant cloner le projet en local sur son ordinateur pour y travailler en parallèle avec Marie.

Si, lors de votre premier push vous avez un message d’erreur indiquant que vous n’avez pas la permission en écriture sur ce dépôt, il y a des chances pour que vous ayez cloné un dépôt qui n’est pas le vôtre, ou pour lequel vous n’êtes pas collaborateur (par exemple, un template de BioDataScience-Course). Faites toujours attention avant de cloner un dépôt et vérifiez vos droits dessus. Sinon, vous pouvez toujours forker un dépôt public appartenant à quelqu’un d’autre, et cloner ensuite votre fork… mais cela est une autre histoire.

Les deux collaborateurs vont pouvoir travailler sur le même document et progresser ensemble dans l’analyse du jeu de données sur la biométrie humaine. En cliquant tout simplement sur le dernier commit réalisé on peut retrouver la succession des commits qui ont été faits jusqu’ici (historique).

Jusqu’à présent, les deux scientifiques ont échangé par mail. Cependant, Il est possible d’être plus efficace et d’utiliser les issues pour cela. La création d’une issue peut se faire facilement comme le montre la procédure ci-dessous.

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. Il ne s’agit pas d’un système de chat comme Discord, messenger,… Vos “memes”, et autres gifs animés pour y 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 pas du tout leur place dans les issues !

Une issue doit également ê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.

GitHub comprend 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.

3.5.2 Gestion de conflit

La collaboration entre plusieurs personnes mène inévitablement à la gestion de conflits. N’ayez pas peur des conflits (au sens de GitHub, en tous cas). Il suffit de les gérer, ce que nous allons apprendre ici.

Imaginons que nos deux collaborateurs réalisent une modification du document biometry_note.Rmd en même temps et sur la même partie du document.

Que va-t-il se passer selon vous ? Lequel des deux collaborateurs va-t-il 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 réalise son push de gérer ce conflit lui-même.

On peut voir que lorsque le push est réalisé, une erreur apparaît. Il faut d’abord réaliser un pull afin de récupérer ce qui est sur GitHub.

Vous pouvez ensuite vous rendre dans chaque fichier problématique pour retrouver la/les zone(s) de conflit (utiliser l’outil de recherche avec l’icône loupe dans l’éditeur RStudio et recherchez par exemple >>>>>).

La résolution est simple à faire. Vous devez choisir la partie qui vous semble la plus pertinente et effacer tout le reste, y compris les balises ajoutées par GitHub.

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.

Lorsque vous vous lancez dans un projet ou revenez vers lui, il faut toujours faire un pull afin de vous assurer que vous travaillez bien avec la dernière version en ligne sur GitHub.

Lorsque vous avez terminé de travailler sur 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) et enfin un push. Ne laissez jamais trainer 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 commitsne viennent rendre la situation plus complexe.

À vous de jouer !

Note : le projet GitHub Classroom suivant est un exercice à réaliser en binôme. Ce projet est également transmodule, ce qui signifie que vous reviendrez dessus à plusieurs reprises au fur et à mesure de votre progression dans la matière afin de compléter votre analyse de ces données, toujours en binômes. Vous formez les binômes librement comme bon vous semble.

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

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

Initiez votre projet GitHub Classroom

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