Les workflows ou les différentes manières de s organiser à plusieurs

Centralisé

C'est le workflow le plus naturel pour les développeurs qui ont déjà utilisé Subversion ou CVS.

Tous les développeurs ont une ou plusieurs copies de travail et communiquent (tirent et poussent) uniquement avec un dépôt central. Ainsi chacun a des droits identiques sur le projet. Le premier qui tire des modifications qui entrent en conflit avec son travail résout le conflit de son côté et impose ses choix aux autres.

Ce workflow est adapté à ces situations :

  • Dans un groupe où chaque développeur travaille sur une partie différente et isolée du projet mais a besoin des modifications des autres
  • Dans un groupe ou tout le monde se fait confiance et où quelles que soient les décisions de résolution de conflit, elles sont acceptées par tout le monde.

central

Totalement decentralisé

Ce workflow est difficile à utiliser quand on est plus de deux développeurs.

Chaque développeur a un dépôt public sur lequel il pousse ses modifications. De temps en temps, un développeur doit puller les modifications sur les dépôts publics des autres, faire le merge et pousser tout ça sur son dépôt public.

decentralized2

Décentralisé avec un "release manager"

Tout le monde a aussi un dépôt public mais il existe un dépôt de référence sur lequel seul le release manager a le droit de pousser. Chaque développeur tire donc depuis ce dépôt de référence et pousse ses modifications sur son dépôt public personnel.

Ce workflow est très adapté aux projets de taille moyenne (entre 4 et 20 personnes) dans lesquels les modifications des développeurs doivent être vérifiées par un chef de projet avant d'être intégrées dans le dépôt de référence.

releasemanager

Hiérarchique

C'est le workflow qu'il peut être nécessaire d'utiliser pour les gros projets. On multiplie les release managers hiérarchiquement pour diviser le travail de controle/acceptation des modifications.

Chaque développeur dispose d'un dépôt public. Chaque développeur fait partie d'un sous groupe du projet. Dans chaque sous-groupe se trouve un "lieutenant" qui tire les modifications des membres du groupe et choisi de les intégrer ou pas dans son dépôt public. Chaque lieutenant fait aussi partie d'un groupe de niveau supérieur dans lequel se trouve aussi un lieutenant. Et ainsi de suite jusqu'au grand chef du projet. Le chef de projet, aussi appelé dictateur, est le seul à pouvoir pousser dans le dépôt de référence. Tout le monde tirer les modifications du dépôt de référence. C'est ainsi qu'est organisé le développement du noyau Linux.

hierarchy