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 serez 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 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 pour accepter ou non de collaborer. S’il accepte, il obtient alors des droits en écriture sur le dépôt de Marie, ce qui lui permettra de réaliser des “pushes”. 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 les mêmes documents et progresser ensemble dans l’analyse du jeu de données sur la biométrie humaine. En cliquant 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” dans le dépôt même pour cela. Vous avez appris à utiliser les issues depuis le chapitre 1 du cours. Dans le dépôt d’exemple, cela se présentera comme ci-dessous.

Petit rappel : 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 !

Rappelez-vous aussi 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.

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.

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 correctement, 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 la dernière version présente sur GitHub.

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 <<<<<).

La résolution du conflit se fait en éditant le fichier. 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” 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 II.

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

Initiez votre projet GitHub Classroom

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