3.5 Travail collaboratif
Jusqu’à présent vous avez réalisé plusieurs assignations individuelles. Cependant, GitHub est prévu pour collaborer. En tant que scientifiques, vous êtes amenés à 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 pushes. Il peut maintenant cloner le projet en local sur son ordinateur pour y travailler en parallèle avec Marie.
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 documents 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.
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 treansitoire 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 situtation plus complexe.
À vous de jouer !
Note : l’assignation GitHub suivante 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 l’assignation A03Ga_urchin.
Si vous êtes un utilisateur non enregistré ou que vous travaillez en dehors d’un cours, faites un “fork” de ce dépôt.
Voyez les explications dans le fichier README.md.
Votre blog
Dans le cadre d’une collaboration entre le cours English For Science et le cours de Science des données I, vous êtes amené à créer un blog scientifique. Ce blog va comprendre des articles qui traitent d’analyse de la littérature de vulgarisation scientifique et de description de données.
Vous devez à présent ajouter disqus à votre blog. Cliquez sur le lien et suivez les instructions : http://biodatascience-course.sciviews.org/sdd_blog/