tite fractale

Pourquoi utiliser Git ?

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 ----------+
                            |
     +----------------------+-----------------------
     |
     |    test_compter.txt depuis dev1 et dev2
     |
     +----------------------------------------------

     win R notepad (aka bloc-notes)

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,

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

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 :

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 à :

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 :

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

2.3.3.2. L’activité personnelle

Chaque ligne correspond grossièrement à une commande.

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 :

 

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

Éviter les conflits

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.




Christophe Gragnic, idée des inspecteurs, le 26/09/2014, 15h05'58".






Page générée le 04/12/2016, 10h08'07" (source).
historique de la page
historique global

 TogetherJS