J'utilise Git au quotidien. Parfois seul, souvent à plusieurs, que ce soit pour des projets professionnels, pour des contributions sur github, gitlab ou sur drupal.org

## Github / Gitlab

Pour éviter de se répéter plusieurs fois, je ne parlerai que de Github, Gitlab aillant des fonctionnalités identiques, parfois nommées différemment. Github est plus largement répandu pour une utilisation open-source, même si gitlab tire de plus en plus son épingle du jeu en bien des points, mais on est alors hors-sujet.
Concernant Github, le fonctionnement des 'pull request' permet d'éviter tout problème. Les modifications demandées sont bien isolées, le mainteneur du projet est libre d'accepter ou non ces commits voir des les assembler en un seul commit si besoin. Il a donc l'interface pour demander au contributeur de respecter les règles de bonne utilisation de git, et dans tous les cas, peut réordonner comme bon lui semble les commits de ce 'pull request', les assembler en un seul etc.

## Drupal.org
S'agissant de drupal.org, le fonctionnement varie par rapport à Github et semble plus archaïque (n'oublions pas que le système et les process sont globalement identiques à l'époque de l'utilisation de CVS), ainsi nous n'avons pas de 'pull request' mais fonctionnons avec des patchs. En revanche, une documentation fixe la charte de bonne utilisation de git, ce qui permet d'aider les contributeurs à apprendre à générer un patch correct et permet au mainteneur de pointer vers cette documentation si besoin.
Le fait de fonctionner par patch joint à une issue permet au mainteneur de créer facilement un commit à partir du patch en question. Dans le cas où le correctif n'est pas encore commité, le système de patchs permet de corriger le module dans son projet tout en conservant l'information que ce module a été modifié et quelle est l'issue traitant de cette modification.
[Voir l'article traitant de la contribution sur Drupal.org](/contribuer-en-tant-que-developpeur-a-drupal-via-drupal-org).

## Patchs Drupal Vs pull request Github

L'interface de Github et des pull request semble plus confortable au premier abord. Toutefois, à l'usage, les patchs sont beaucoup plus pratiques.

D'un point de vue de l'interface, couplé à l'extension de navigateur [Dreditor](https://dreditor.org/), les patchs sont lisibles, autant que peut l'être la visualisation d'un commit sur github.

*Capture d'écran de Dreditor*

Là où github permet de visualiser l'avancée de la contribution commit après commit (et donne donc accès à chaque fois à la visualisation du fichier complet modifié si besoin), il ne permet pas en revanche facilement de voir toutes les modifications apportées en un coup d'oeil (plusieurs commits), il faut alors plusieurs clics pour arriver au résultat. À contrario, le fait d'avoir une visibilité par commit permet de voir en un coup d'oeil les modifications entre chaque commit. Côté Drupal, il faut que le contributeur proposant le patch mette bien à disposition un fichier interdiff qui est également pris en compte par Dreditor pour que l'on puisse voir la différence entre les 2 derniers patchs.

*Patch et interdiff sur une issue sur Drupal.org*

L'utilisation des patchs est régulière dans les projets, lorsque l'on souhaite corriger des problèmes sur des modules contrib en attendant que la correction soit disponible sur une version stable. On applique alors directement le patch ou on passe par une solution telle que [Drush Make](http://www.drush.org/en/master/make/). On peut très bien imaginer faire de même avec des commits de pull requests, mais cela veut dire qu'il faut alors se baser sur les modifications d'un ou plusieurs commits. Possible donc, mais plus complexe que de télécharger et appliquer un patch.

Le second avantage le plus important à mon sens pour le système de patchs est de pouvoir proposer 2 versions (ou plus) de patchs complètement différents. Il est ainsi possible de proposer plusieurs pistes de résolution d'un problème dans la même issue. On peut donc commencer sur une solution, pour finir sur une meilleure solution proposée par un autre contributeur, chose qui deviendrait invisible avec un pull request ou nécessiterait plusieurs pull requests et un sujet commun pour débattre des différentes solutions.

Le premier avantage -pour l'utilisation de patchs, et rédhibitoire à l'utilisation de pull requests- est que seuls les patchs permettent de contribuer simplement à plusieurs personnes sur une issue. Le système de pull request rend la résolution d'une issue et la proposition de patchs/pull request difficile voir impossible à plusieurs. Or c'est ce qui fait la force de Drupal aujourd'hui. Une personne peut proposer une version d'un patch, et une autre personne peut directement proposer une correction de ce patch à la suite, qui pourra être complété par une autre personne etc.

La migration de git Drupal vers github et vers les fonctionnalités de github (issues/pull requests) a de nombreuses fois été évoqué. Ce dernier argument en faveur de patchs justifie pour moi à lui seul le fait de ne pas basculer sur un tel système.