3.6 Travail collaboratif II

GitHub est une plateforme collaborative. C’est dans ce sens que GitHub a été développé. L’un de ses objectifs est de fournir tous les outils pour permettre le travail en collaboration. GitHub comprend plus de 100 millions de dépôts. Vous vous doutez bien que vous n’avez pas la possibilité de cloner un dépôt, de l’éditer et d’y ajouter vos modifications via un push sur un projet de sociétés comme Meta, Microsoft ou encore Google. Il en est de même pour une grande partie des dépôts hébergés sur notre organisation BioDataScience-Course.

Deux possibilités s’offrent principalement à vous. Première option, vous intégrez une équipe pour travailler sur un projet commun. Il faut dans ce cas ajouter l’utilisateur au projet. Néanmoins, être ajouté à un projet ne signifie pas que l’on peut faire ce que l’on veut. Il y a cinq rôles allant de l’accès en lecture, ce qui signifie que l’on peut voir la progression d’un projet et interagir dans les issues, en passant par le droit en écriture, et pour finir, le niveau le plus élevé est l’administrateur de projet qui peut aller jusqu’à supprimer le projet de GitHub. Par exemple, vous n’avez pas le droit administrateur sur vos dépôts d’exercice. Cela nous assure que, par mégarde, vous ne supprimiez vos projets.

La seconde possibilité est de contribuer à un projet en partant d’une copie de ce dernier. Pour dupliquer un dépôt existant sur GitHub, on va réaliser un “fork”. Ce fork peut soit être réalisé directement dans votre compte, soit au sein d’une organisation à laquelle vous avez accès. Vous pouvez aussi renommer le projet si vous le souhaitez. Vous avez tous les droits sur votre copie. Par exemple, lorsque vous réalisez un exercice N3 ou N4, GitHub Classroom réalise un fork pour vous. Il part d’un dépôt de référence sur lequel vous n’avez pas le droit en écriture et réalise une copie hébergée dans l’organisation BioDataScience-Course.

3.6.1 Projet commun

Utilisons le projet Z03Ga_00M_commun_project sur lequel arthurpeeters travaille. Suite à des échanges avec oliviamaes, ils vont collaborer dans un projet commun. Pour ce faire, Arthur doit donner accès à Olivia. Pour cela, il se rend dans son dépôt, puis va dans Settings puis Collaborators and teams. Il clique sur Add people et sélectionne ou entre le login GitHub de sa collaboratrice (oliviamaes). Il définit le rôle d’Olivia dans ce dépôt par la même occasion.

Olivia a à présent la possibilité de réaliser des push sur le dépôt. Olivia peut cloner le projet en local sur son ordinateur pour y travailler en parallèle avec Arthur. Afin de limiter les conflits, il est néanmoins conseillé d’organiser la répartition du travail comme présenté dans le module précédent.

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…

3.6.2 Projet extérieur

Comme mentionné précédemment, il est possible de contribuer à des projets publics même si vous n’avez pas le droit de réaliser des modifications directement dans ces derniers. Pour ce faire, il faut réaliser un fork du projet (flèches grises). Un fork est une copie sur GitHub d’un projet également hébergé sur GitHub. Ce nouveau projet peut être renommé comme vous le souhaitez ou garder le même nom. Il s’agit de votre projet. Vous avez par conséquent bien plus de droits sur ce dernier. Vous pouvez, par exemple, réaliser des commits, des pulls et des pushs.

Enfin, il est possible de réaliser une pull request (flèche verte), c’est-à-dire de proposer d’intégrer vos modifications au dépôt parent. La fusion de vos ajouts avec le projet parent est réalisée par l’auteur du dépôt parent. Cette fusion est un merge. Cette manière de travailler est saine. Les commits sont attribués à chaque auteur. Il est possible de retrouver l’auteur de chaque commit.

Ce nouveau projet garde un lien avec le projet parent. Cela permet de synchroniser votre dépôt avec le dépôt parent afin de bénéficier de toutes les mises à jour de ce dernier.

Un projet parent et un projet forké sont présentés pour illustrer le processus. Ils sont disponibles ici : Z03Gb_00M_forked-project-oliviamaes et Z03Gb_00M_forked-project-arthurpeeters.

On observe que le projet a été forké lorsque le projet n’avait que 2 commits, alors qu’à présent il en a plus.

3.6.3 Branches de git

Le gestionnaire de version git peut être envisagé comme une arborescence de branches. Par défaut, votre dépôt à une branche qui se nomme main (avant 2020, les branches par défaut se nommaient master). Dans le cadre de nos cours, nous travaillerons dans la branche main uniquement.

Les branches comme branche 1 ou branche 2 sur la figure ci-dessous ont pour objectif de réaliser des essais. Tous les commits en vert ou en orange ne sont pas réalisé dans la branche principale qui est main. Cela signifie que la branche main n’est pas affectée.

Vous pouvez observer que l’on part d’un commit d’une branche dans notre cas la branche main

Une branche peut être abandonnée comme la branche 1 ou encore fusionnée avec la branche principale comme la branche 2.