5.1 Git distribué - Développements distribués

Dans les systèmes centralisés, il n’y a généralement qu’un seul modèle de collaboration, la gestion centralisée. Un concentrateur ou dépôt central accepte le code et tout le monde doit synchroniser son travail avec. Les développeurs sont des nœuds, des consommateurs du concentrateur, seul endroit où ils se synchronisent.

Cela signifie que si deux développeurs clonent depuis le concentrateur et qu’ils introduisent tous les deux des modifications, le premier à pousser ses modifications le fera sans encombre. Le second développeur doit fusionner les modifications du premier dans son dépôt local avant de pousser ses modifications pour ne pas écraser les modifications du premier. Ce concept reste aussi vrai avec Git qu’il l’est avec Subversion (ou tout autre CVCS) et le modèle fonctionne parfaitement dans Git.

Si vous êtes déjà habitué à une gestion centralisée dans votre société ou votre équipe, vous pouvez simplement continuer à utiliser cette méthode avec Git. Mettez en place un dépôt unique et donnez à tous l’accès en poussée. Git empêchera les utilisateurs d’écraser le travail des autres.

Supposons que John et Jessica commencent en même temps une tâche. John la termine et pousse ses modifications sur le serveur. Puis Jessica essaie de pousser ses modifications, mais le serveur les rejette. Il lui indique qu’elle tente de pousser des modifications sans avance rapide et qu’elle ne pourra le faire tant qu’elle n’aura pas récupéré et fusionné les nouvelles modifications depuis le serveur. Cette méthode est très intéressante pour de nombreuses personnes car c’est un paradigme avec lequel beaucoup sont familiarisés et à l’aise.

Ce modèle n’est pas limité aux petites équipes. Avec le modèle de branchement de Git, des centaines de développeurs peuvent travailler harmonieusement sur un unique projet au travers de dizaines de branches simultanées.

Comme Git permet une multiplicité de dépôts distants, il est possible d’envisager un mode de fonctionnement où chaque développeur a un accès en écriture à son propre dépôt public et en lecture à tous ceux des autres. Ce scénario inclut souvent un dépôt canonique qui représente le projet « officiel ». Pour commencer à contribuer au projet, vous créez votre propre clone public du projet et poussez vos modifications dessus. Après, il suffit d’envoyer une demande au mainteneur de projet pour qu’il tire vos modifications dans le dépôt canonique. Il peut ajouter votre dépôt comme dépôt distant, tester vos modifications localement, les fusionner dans sa branche et les pousser vers le dépôt public. Le processus se passe comme ceci (voir Le mode du gestionnaire d’intégration.) :

C’est une gestion très commune sur des sites « échangeurs » tels que GitHub ou GitLab où il est aisé de dupliquer un projet et de pousser ses modifications pour les rendre publiques. Un avantage distinctif de cette approche est qu’il devient possible de continuer à travailler et que le mainteneur du dépôt principal peut tirer les modifications à tout moment. Les contributeurs n’ont pas à attendre le bon vouloir du mainteneur pour incorporer leurs modifications. Chaque acteur peut travailler à son rythme.

C’est une variante de la gestion multi-dépôt. En général, ce mode est utilisé sur des projets immenses comprenant des centaines de collaborateurs. Un exemple célèbre est le noyau Linux. Des gestionnaires d’intégration gèrent certaines parties du projet. Ce sont les lieutenants. Tous les lieutenants ont un unique gestionnaire d’intégration, le dictateur bienveillant. Le dépôt du dictateur sert de dépôt de référence à partir duquel tous les collaborateurs doivent tirer. Le processus se déroule comme suit (voir Le processus du dictateur bienveillant.) :

Ce schéma de processus n’est pas très utilisé mais s’avère utile dans des projets très gros ou pour lesquels un ordre hiérarchique existe, car il permet au chef de projet (le dictateur) de déléguer une grande partie du travail et de collecter de grands sous-ensembles de codes à différents points avant de les intégrer.

Voilà donc quelques-uns des flux de travail les plus utilisés avec un système distribué tel que Git, mais on voit que de nombreuses variations sont possibles pour mieux correspondre à un mode de gestion réel. À présent que vous avez pu déterminer le mode de gestion qui s’adapte à votre cas, nous allons traiter des exemples spécifiques détaillant comment remplir les rôles principaux constituant chaque mode. Dans le chapitre suivant, nous traiterons de quelques modèles d’activité pour la contribution à un projet.