Environnement de travail du projet

Le projet s’effectue dans un environnement GitHub, un service en ligne qui permet d’héberger des projets de développement logiciel.

Créer un compte GitHub

Pour réaliser le projet, s’il on n’en dispose pas déjà, il faut créer un compte GitHub : Sign up

• email : celui de votre compte Esiee ;

• password ;

• username : PrenomNom (identique à celui de votre email ESIEE).

Important

Il est fondamental de suivre les conventions ci dessus, car l’activité de chacun des membres du projet est tracée et utilisée pour l’évaluation. Une identification incorrecte pourrait vous pénaliser.

Si vous disposez déjà d’un compte GitHub que vous souhaitez continuer à utiliser pour ce projet, vous pouvez modifier le username pour qu’il corresponde à la convention ci dessus.

Avertissement

Pour la suite vous devez être connecté à votre compte GitHub.

Le repo distant

Disposer d’un compte GitHub vous permet de disposer d’un espace de stockage pour votre projet. Cet espace est appelé repo distant (pour repository).

Tout au long de la vie du projet, le repo distant sera le référentiel du projet en ce sens, qu’à chaque étape, le repo distant contiendra l’ensemble des fichiers et l’historique des modifications. Voyons maintenant comment utiliser cet espace de stockage.

Contexte mono utilisateur

On se place dans un contexte mono utilisateur qui dispose d’un repo distant sur GitHub. La communication avec le repo distant (unique) peut se faire à travers :

• ➊ un codespace, c’est à dire un environnement de développement en ligne, accessible à travers un navigateur web, qui permet de travailler sur le projet sans avoir à installer quoi que ce soit sur sa machine. Un codespace est un container Docker (une machine virtuelle légère) qui est créé à la demande et qui est associé à un repo distant. Il nécessite un compte GitHub ;

• ➋ un environnement de développement VS Code classique sur une ou plusieurs machines locales de l’utilisateur.

Un repo distant unique et plusieurs environnements de développement associés.

Par la suite il est très fortement conseillé de travailler exclusivement à partir du seul codespace, ce qui présente les avantages suivants:

• la connexion avec le repo distant est déjà paramétrée ;

• il est accessible depuis n’importe quelle machine à partir d’un simple navigateur web ;

• aucune installation locale n’est nécessaire.

Environnement conseillé : un repo distant unique et un codespace

Avertissement

En cas d’utilisation de multiples environnements de développement, il est fondamental de synchroniser régulièrement le repo distant avec chacun des environnements de développement pour éviter les conflits.

1. Un repo distant est un espace de stockage pour un projet.

2. Il est possible de travailler sur un projet sans avoir à installer quoi que ce soit sur sa machine.

3. Il est possible d’accéder à un repo distant à partir de n’importe quelle machine.

4. Il est possible de travailler sur un projet à partir de plusieurs environnements de développement distincts.

5. Il est conseillé d’installer un environnement de développement local sur sa machine

6. Il est possible d’installer un environnement de développement local sur sa machine

7. Un codespace est un environnement de développement local

8. Un codespace nécessite un compte GitHub

9. Il est possible de travailler sur un projet à partir d’un codespace

10. Il est fortement conseillé de travailler sur un projet à partir d’un codespace

11. Un codespace se comporte comme une machine virtuelle légère

Contexte multi utilisateur

Le projet s’effectue en binôme. Dans ce cadre là, il y a toujours un seul repo distant et donc un seul référentiel pour le projet. Mais plusieurs environnements de développement partagés entre les utilisateurs Alice et Bob.

Important

Pour la suite, on se place dans l’environnement conseillé ci dessous, c’est à dire un repo distant unique et un codespace par utilisateur.

Un seul repo distant et un codespace par utilisateur

Puisqu’il y a un seul et unique référentiel (repo distant) pour le projet, le repo distant devra être créé par un utilisateur, qui devra ensuite ajouter les autres utilisateurs comme collaborateurs du projet. Pour la suite, et par convention, on considère que :

• Alice est propriétaire du projet. Elle crée le repo distant et invite Bob comme collaborateur ;

• et Bob est collaborateur du projet. Il est invité par Alice et peut contribuer au projet.

Important

Il faut décider dès à présent dans le binôme, qui va jouer le rôle de Alice et qui va jouer le rôle de Bob. Ces rôles sont définitifs et ne peuvent pas être changés en cours de projet.

1. Un repo distant peut être partagé entre plusieurs utilisateurs.

2. Un repo distant peut avoir plusieurs propriétaires.

3. Un repo distant peut avoir plusieurs collaborateurs.

4. Le repo distant est le référentiel unique du projet, même s’il y a plusieurs environnements de développement.

5. Le repo distant est le référentiel unique du projet, même s’il y a plusieurs collaborateurs.

6. Chaque collaborateur a son propre repo distant.

7. Il est possible de connecter plusieurs environnements de développement distincts à un repo distant

8. Ces environnements de développement distincts doivent appartenir à un seul propriétaire

9. Je développe le projet directement sur le repo distant

10. Je développe le projet à partir d’un environnement de développement connecté au repo distant

11. Je synchronise régulièrement mon environnement de développement avec le repo distant

12. Je peux travailler sur le projet à partir de n’importe quel environnement de développement connecté au repo distant

13. Je peux me connecter au codespace de mon binôme

Rentrons maintenant dans le détail de la création du repo distant et de l’association des environnements de développement.

Alice crée le repo distant

Le repo distant est créé une seule fois pour toutes, par le propriétaire du projet, ici Alice. Il peut être créé vide ou à partir d’un repo distant existant. C’est ici la deuxième solution qui est retenue, en utilisant le starter code disponible dans ce dépôt utilisé comme template.

• Use this template Create a new repository TBA Create repository

Après création, Alice est propriétaire d’un repo distant, visible à l’adresse https://github.com/Alice/TBA, qui est l’exacte copie du template. Puisque ce repo distant est public, il est également visible par Bob. Puisque Bob n’a pas encore été déclaré comme collaborateur, il ne peut pas y contribuer pour l’instant.

Alice crée le repo

1. Un utilisateur GitHub quelconque peut créer un repo distant.

2. Un repo distant peut être créé vide.

3. Un repo distant doit être créé vide.

4. Un repo distant peut être créé à partir d’un repo distant existant.

5. Un repo distant doit être créé à partir d’un repo distant existant.

6. Sans manipulation particulière, le repo distant créé par Alice est accessible uniquement par Alice.

7. Avec une manipulation particulière, le repo distant créé par Alice peut être accessible par Bob.

Astuce

Pour la suite, l’adresse du repo distant sera référencée par [GITHUB_REPOSITORY_HOMEPAGE].

Il faut maintenant que Bob soit ajouté par Alice comme collaborateur pour pouvoir contribuer au projet.

Ajouter Bob comme collaborateur

Pour un travail en binome efficace, il faut que chacun des membres puisse ajouter/modifier/supprimer des fichiers dans le repo distant. C’est automatiquement le cas pour Alice qui est propriétaire du repo distant.

Pour que Bob puisse contribuer au projet, Alice doit l’inviter explicitement à partir de

[GITHUB_REPOSITORY_HOMEPAGE] >> Settings >> Collaborators >> Add people

en lui donnant le rôle de Collaborator.

Bob reçoit alors une invitation. Il doit l’accepter pour pouvoir contribuer au projet.

Alice ajoute Bob comme collaborateur

1. Seul le propriétaire du repo distant peut ajouter un collaborateur.

2. Un collaborateur peut utiliser GitHub pour être associé à un repo distant.

3. Un collaborateur peut ajouter des fichiers à un repo distant.

4. Un collaborateur peut modifier des fichiers dans un repo distant.

5. Un collaborateur peut supprimer des fichiers dans un repo distant.

Associer un codespace

Depuis la [GITHUB_REPOSITORY_HOMEPAGE], Alice et Bob doivent chacun démarrer leur propre codespace (il n’est pas possible de partager un codespace).

Code Codespaces Create codespace on main

Avertissement

Une fois créé, le codespace est accessible à une adresse du type https://[STRANGE_CODESPACE_NAME].github.dev/. Les codespaces de Alice et de Bob sont indépendants et n’ont donc pas la même adresse.

Les codespaces sont associés au compte Github. Il n’est donc pas possible pour Alice d’accéder au codespace de Bob et vice versa (une erreur 404 est générée).

La seule façon de partager du code entre Alice et Bob est de passer par le repo distant, qui est, on le rappelle, le référentiel unique du projet. Il est important :

• de bien se répartir le travail pour limiter les conflits ;

• de synchroniser régulièrement le repo distant avec les environnements de développement.

On retrouve la configuration exposée au paragraphe Contexte multi utilisateur avec les codespaces associés à chaque utilisateur et connectés au repo distant. C’est la configuration de base.

Astuce

Les codespaces sont gérés sur la page https://github.com/codespaces. Il faut veiller à stopper les codespaces après utilisation ou à supprimer les codespaces inutilisés pour ne pas consommer des ressources inutilement.

1. On peut partager un codespace entre plusieurs collaborateurs

2. Chaque collaborateur doit démarrer son propre codespace

3. Les codespaces sont associés au compte GitHub de l’utilisateur

4. Les codespaces sont associés au projet

5. Il est possible de supprimer un codespace inutilisé

6. Il est impératif de stopper un codespace après utilisation

7. A l’association du codespace avec le repo distant, le repo distant est synchronisé avec le codespace

Important

A son démarrage, le codespace dispose d’un repo local qui est synchronisé avec le repo distant. Il est donc important de synchroniser régulièrement les repos locaux (un repo local pour chacun des environnements de développement associé) avec le repo distant pour éviter les conflits.

Le workflow

Important

Les informations ci dessous sont importantes et devront être consultées tout au long de la vie du projet.

Le repo distant est le référentiel du projet. A ce titre, il doit être régulièrement synchronisé avec le repo local de chacun des codespaces. Alice et Bob devront suivre la démarche suivante :

• synchronisation descendante du repo local à partir du repo distant : git pull

• modification/ajout/suppression de fichiers dans le codespace

• ajout à l’index du repo local : git add .

• insertion dans l’historique du repo local : git commit -m "message explicatif"

• synchronisation montante du repo local avec le repo distant: git push

1. La synchronisation descendante consiste à récupérer les modifications du repo distant

2. La commande git pull transfère l’historique du repo distant vers le repo local du codespace

3. La synchronisation montante consiste à envoyer les modifications du repo local vers le repo distant

4. La commande git push envoie les modifications du repo local vers le repo distant

5. Il faut ajouter les fichiers à l’index avant de les insérer dans l’historique du repo local

6. L’historique est d’abord généré dans le repo local

7. La commande git commit ajoute un élément à l’historique du repo local

8. La commande git commit est accompagnée d’un message explicatif

9. Les modifications sont effectuées dans le repo local et transférées vers le repo distant

10. Les modifications disponibles dans le repo distant peuvent être transférées dans le repo local

Etape initiale

Au démarrage, le repo distant et le repo local de chacun des codespaces sont synchronisés comme l’indique la figure ci dessous. 1e14 est le commit initial et ne contient que le fichier README.md.

Pour Alice, dans le terminal du codespace

Alice $ git log --format="%h"
1e14

Même chose pour Bob

Bob $ git log --format="%h"
1e14

Alice ajoute du code

Alice ajoute du code dans son codespace.

Puis elle ajoute ces fichiers à l’index, et crée le commit. Dans le terminal du codespace

Alice $ git add .
Alice $ git commit -m "Ajout de code"
Alice $ git log --format="%h"
78de
1e14

A présent, le codespace de Alice est en avance sur le repo

Alice $ git status

# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

Alice synchronise son codespace avec le repo

Pour maintenir le repo à jour avec ses dernières modifications, Alice doit synchroniser son codespace avec le repo. Elle pousse son commit 78de

Alice $ git push

Le repo est à jour mais pas le codespace de Bob

Alice $ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

Bob récupère les modifications d’Alice

Bob récupère les modifications d’Alice en synchronisant son codespace avec le repo. Il tire le commit 78de

Bob $ git pull
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
From https://github.com/Alice/TBA
   1e14..78de  master -> origin/master
Updating 1e14..78de
Fast-forward
file1.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Le codespace de Bob est synchronisé avec le repo

Bob $ git status
On branch master
Your branch is up to date with 'origin/master'.
$ git log --format="%h"
78de
1e14

Bob ajoute du code

Il peut se trouver une situation dans laquelle Bob travaille de son côté, et crée le commit e094

Bob $ git add .
Bob $ git commit -m "Ajout d'autre code"
Bob $ git log --format="%h"
   e094
   1e14

Lorsque Bob veut synchroniser son codespace avec le repo, il va se produire une erreur puisqu’il ne dispose pas du commit 78de:

Bob $ git push
To github.com:Alice/TBA
! [rejected]        master -> master (fetch first)
error: impossible de pousser des références vers 'github.com:Alice/TBA'
astuce: Les mises à jour ont été rejetées car la branche distante contient du travail que
astuce: vous n'avez pas en local. Ceci est généralement causé par un autre dépôt poussé
astuce: vers la même référence. Vous pourriez intégrer d'abord les changements distants
astuce: (par exemple 'git pull ...') avant de pousser à nouveau.
astuce: Voir la 'Note à propos des avances rapides' dans 'git push --help' pour plus d'information.

Si les modifications de Bob ne sont pas en conflit avec celles d’Alice, il peut tirer les modifications d’Alice, ajouter ses fichiers à l’index, créer le commit et pousser les modifications

Bob $ git pull
Bob $ git add .
Bob $ git commit -m "Ajout d'autre code"
Bob $ git log --format="%h"
   e094
   78de
   1e14

Bob peut synchroniser son codespace avec le repo

Bob $ git push

Le repo est à jour et Alice peut récupérer les modifications de Bob

Bob $ git pull

Résolution de conflit

Il peut y avoir une situation pour laquelle Bob a effectué des modifications contradictoires avec le repo, par exemple modifié le même fichier qu’Alice. Dans ce cas, il y a un conflit et lorsque Bob tire les modifications d’Alice, il obtient un message d’erreur

Bob $ git pull
! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/yourusername/yourrepo'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g. 'git pull')
hint: before pushing again.

Bob doit résoudre le conflit en éditant le fichier conflictuel. Il doit supprimer les marqueurs de conflit et choisir les modifications à conserver. Une fois le conflit résolu, il ajoute le fichier à l’index, crée un commit de résolution de conflit qui fait l’interface entre 78de et e094

Bob $ git add .
Bob $ git commit -m "Résolution du conflit"
Bob $ git log --format="%h"
   e094
   4a82
   78de
   1e14

Bob peut alors synchroniser son codespace avec le repo et il sera possible à Alice de récupérer les modifications apportées par Bob

Bob $ git push