1. Problématique

1.1. Mise en place

L’idéal est de disposer d’un dossier distant, sur lequel on peut travailler à plusieurs. Sinon, il est toujours possible de simuler cette configuration sur une même machine en ouvrant le même fichier texte depuis deux instances de Bloc-Notes (ou tout autre éditeur).

1.2. L’activité

Soit un fichier test_compter.txt (disponible ici) dans lequel il y a au départ :

dev 1
1
2

dev 2
1
2

dev 3
1
2

...

tous
1
2

On veut simplement continuer chaque liste de nombres, en enregistrant entre chaque ajout de ligne. Les développeurs d’une même équipe travaillent sur le même fichier.

 lecteur distant -----------+
                            |
                +-----------------------+
                |                       |<---- dev 1 lecture/écriture
                |    test_compter.txt   |
                |                       |<---- dev 2 lecture/écriture
                +-----------------------+-

     Utiliser bloc-notes (Win+R puis notepad)

Exemple pour le développeur numéro 2 :

1. ouvrir le fichier avec Bloc-Notes,
2. ajouter « 3 » à la liste dont le titre est « dev 2 »,
3. enregistrer,
4. ajouter « 3 » (ou « 4  si quelqu’un est passé avant) à la liste dont le titre est « tous »,
5. enregistrer,
6. ajouter « 4 » à la liste dont le titre est « dev 2 »,
7. enregistrer,
8. …

Le but est d’obtenir :

dev 1
1
2
3
4
5

dev 2
1
2
3
4
5

dev 3
1
2
3
4
5

...

tous
1
2
3
4
5

Une fois que vous avez fini, chaque développeur ferme le fichier et l’ouvre à nouveau pour constater le résultat.

Après un petit moment de concertation au sein de l’équipe pour élaborer une stratégie, il est possible de retenter cette expérience.

Il est aussi intéressant de retenter l’expérience en utilisant Notepad++ plutôt que Bloc-Notes.

2. Solutions

2.1. Copies

Ça ne fonctionne tout simplement pas.

2.2. Verrous

On peut utiliser différentes méthodes pour marquer un fichier comme « Vérrouillé pour modifications ».

• une convention entre codeurs (un préfixe, un suffixe ou autre), mais le risque d’erreur n’est pas nul,
• un système de versionning (voir la doc de Subversion à ce sujet.

C’est assez efficace mais cela ralentit le travail en équipe si un fichier est verrouillé pour peu ou même rien : il faut donc que l’équipe communique bien.

2.3. Un système de gestion de versions

Cette activité part d’un travail en équipe, mais même si on travaille seul, le versionning reste très intéressant.

2.3.1. Contrôle des sources

Même si, dans un moment intense de création de code, vous êtes parti faire un tour au réfrigérateur et que votre chat est venu ronronner sur votre clavier, il peut avoir :

• tapé aléatoirement dans votre fichier en cours d’édition,
• essayé de vous faire une blague en créant un bug subtil dans un autre fichier,

vous garderez la maîtrise de votre code.

2.3.2. Suivi

Les systèmes de versionning propose toujours une liste des modifications effectuées depuis le moment où le projet a été rentré dans le dépôt. Cela peut servir à :

• Lister les nouveautés d’un logiciel (en d’autres termes générer un changelog, par exemple :
  • celui du projet Rockbox,
  • la page modifications de ce site, (voir l’article correspondant dans le blog),
• Faire des statistiques, seul ou en équipe (voir cet article fêtant le millième commit sur ce site).

2.3.3. Travaux pratiques

2.3.3.1. Mise en place

À nouveau, l’idéal serait de disposer d’un dossier distant, mais on peut simuler la configuration :

• pour l’activité personnelle, en clonant un dépôt local,
• pour l’activité en équipe, en ouvrant deux terminaux qui clonent src (pseudo-distant) vers src1 et src2 (les deux pseudo-locaux, un pour chaque développeur fictif (ou réel)).

Quelques connaissances basiques sur la manipulation de systèmes de type UNIX sont nécessaires, ainsi que quelques sous-commandes de git :

• se déplacer avec cd chemin (les partages Windows sont accessibles avec par exemple //xxx.xxx.xxx.xxx/reste/du/chemin/, git bash here sur le dossier distant peut aider),
• créer un répertoire avec mkdir chemin,
• déplacer un répertoire ou un fichier avec mv src dest,
• supprimer un répertoire avec rmdir chemin,
• supprimer quelque chose avec rm chemin,
• git init pour transformer le répertoire courant en dépot,
• git config user.name "mon nom" pour configurer son nom,
• echo texte >> fichier pour écrire dans un fichier,
• git add fichier pour préparer les modifications d’un fichier au commit,
• git commit -m "message" pour commiter,
• git clone adresse chemin/du/clone pour cloner un dépôt,
• git push origin master pour pousser vers le dépôt origin les derniers commits de la branche master,
• git config --bool core.bare true pour forcer un dépôt à être bare,
• git fetch origin pour récupérer les objets du dépôt origin,
• git merge origin/master pour incorporer les changements du dépôt origin (une fois que ses objets ont été récupérés).

2.3.3.2. L’activité personnelle

Chaque ligne correspond grossièrement à une commande.

• Dans un répertoire distant,
  • créer un répertoire src_nom_du_dev.
  • Pour que ce répertoire devienne un dépôt, lancer git init dedans.
  • Créer un fichier source de test contenant une seule ligne, puis
  • commiter les modifications (deux commandes).
• Dans un répertoire local,
  • cloner le dépôt distant que vous venez de créer vers un dépôt src, puis
  • vérifier que votre fichier de test ainsi que son histoire (le premier commit) est bien dans le clone.
  • Ajouter une ligne au fichier de test, puis commiter les modifications (trois commandes).
  • Tenter de pousser vers le dépôt d’origine. Git devrait se plaindre que le dépôt distant n’est pas bare, c’est-à-dire tout nu. En effet, un dépôt qui reçoit des commits via un push ne doit pas avoir de fichiers, mais uniquement posséder l’histoire.
• Nous allons ici transformer le dépôt distant src_nom_du_dev en dépôt bare.
  • Déplacer le .git qu’il contient à côté du src_nom_du_dev tout en le renommant en src_nom_du_dev.git.
  • Supprimer le répertoire src_nom_du_dev, c’est son contenu qui gênait.
  • Forcer src_nom_du_dev.git à être un dépôt bare.
• Dans le répertoire local, retenter le push.

2.3.3.3. L’activité en équipe

Les trois premiers à avoir fini l’activité personnelle ci-dessus se mettent en équipe. Idem pour les trois suivants, etc…

On reprend la première activité de cette page, mais cette fois-ci en utilisant un outil adéquat. Le chef d’équipe initialise un dépôt distant accessible à l’équipe, contenant le fichier sur lequel travailler, puis les développeurs comptent dans leur section et dans la section commune, en commitant et en poussant à chaque fois qu’une ligne est modifiée.

Attention : Une étape supplémentaire sera parfois nécessaire avant de pousser. En effet, un de vos collaborateur aura peut-être modifié le dépôt avant vous (et c’est bien le but du travail en équipe). Il faudra dans ce cas :

1. récupérer (fetch en anglais) les objets du dépôt d’origine, ceux que vous n’avez pas encore correspondent aux changement effectués par les autres,
2. incorporer (merge en anglas) ces changements dans votre dépôt pour le mettre à jour.

Remarques :

• Il est préférable d’utiliser Notepad++.
• Il est tentant d’écrire n’importe quoi en effaçant tout ce qu’ont fait les collaborateurs, mais d’un point de vue des versions et des conflits, ça devient très complexe pour des débutants. Utilisez le fichier découpé en sections comme dans la première activité de cette page, (disponible ici) et comptez sagement.
• Une fois que c’est compris, on peut faire apparaître des conflits en « signant » chaque ligne ajoutée :

dev 1
1
2
3 dev 1
4 dev 1

dev 2
1
2
3 dev 2
4 dev 2

dev 3
1
2
3 dev 3
4 dev 3

...

tous
1
2
3 dev 1
4 dev 3
5 dev 2

Où apparaissent les conflits ? Où n’apparaissent-ils pas ?

2.3.3.4. Un peu d’humour

2.3.3.5. La suite

Il est possible d’organiser l’équipe en y choisissant un ou plusieurs mainteneurs. Voir la présentation sur Github.