révision de code avec git-flow et github

Avec git et github classiques, je peux effectuer une révision de code en créant simplement une demande d'extraction de la branche que je travaille sur la branche principale. Comment ferais-je des critiques de code avec git-flow? Avec un flux de travail tel que "finition de la fonctionnalité de flux git", je ne comprends pas vraiment où la révision du code a lieu et comment Git-flow ou git peut faciliter cette révision.

Nous sommes tombés sur ce problème précis récemment. Nous aimons vraiment git flow, car il utilise un bon niveau de sémantique (en utilisant le même niveau que celui utilisé dans la discussion en équipe: "Je vais démarrer la fonctionnalité A" plus que "je vais créer une branche, la vérifier"), tandis que git est très au niveau "implémentation" (ce qui est bon et utile aussi, mais différent).

Le problème que nous avons est git feature finishlié au fusionnement de la branche dans le développement, alors que nous souhaitons qu'une demande d'extraction soit envoyée et que (c'est important) fusionnée par le relecteur , et non le committer, pour mettre l'accent sur la propriété de l'équipe.

Notre solution actuelle:

1. Quelqu'un utilise git flow pour créer une branche de fonctionnalité
2. Une fois terminé, il crée une demande de tirage (en utilisant github)
3. La révision a lieu, avec des commits supplémentaires potentiels
4. La demande d'extraction est fusionnée à l' aide de GitHub par le relecteur .
5. Il n'y a pas de finition de la fonctionnalité de flux git (car la branche est déjà fusionnée)

Ceci est conforme à notre pratique, avec l’inconvénient d’exiger la suppression de la branche nous-mêmes (car nous n’avons pas l’arrivée finale). Notre prochaine étape sera probablement de réimplémenter certaines parties de git flow (car il s’agit principalement d’enchaîner les commandes git) pour en tenir compte (avoir la partie "nettoyage" de la finition, sans la fusion).

Le processus utilisé par l'équipe avec laquelle je travaille est le suivant:

1. Créer une branche de fonctionnalité: git flow feature start module_1
2. Le code est mis à jour sur la branche de fonctionnalité
3. Au fur et à mesure que les modifications sont validées, elles sont poussées vers GitHub (ou une fois à la fin si souhaité)
4. Lorsque la fonctionnalité est terminée, une demande d'extraction est ouverte dans la comparaison GitHub developet la branche de fonctionnalitémodule_1
5. L'équipe examine la demande d'extraction et fait des commentaires
6. Toute modification de la demande d'extraction est apportée à la branche de fonctionnalité.
7. Une fois que toutes les modifications ont été intégrées dans la branche de fonctionnalité, celle-ci est terminée: git flow feature finish module_1
8. La developbranche est poussée vers GitHub (GitHub marque automatiquement la demande d'extraction comme fermée / fusionnée lorsque cela se produit)

Normalement tout ce processus est fait par l'auteur original mais ce n'est pas obligatoire. Toute personne de notre équipe peut intervenir et suivre ce processus à tout moment. Tout ce qu'ils ont à faire est de vérifier la branche de fonctionnalités et de poursuivre le processus. Ceux qui courent déjà git flow feature finish module_1auront le luxe de supprimer leur branche de fonctionnalité locale, mais ceux qui ont vérifié la branche doivent le faire manuellement s'ils veulent utiliser quelque chose comme git branch -D feature/module_1.

Pour les correctifs, nous utilisons une approche similaire et créons la demande d'extraction dans GitHub avant de terminer le correctif.

Si vous effectuez des révisions de code, je supposerai que vous disposez d'un référentiel central contenant le code "officiel". Les développeurs tirent de et repoussent vers ce référentiel central.

Lorsque vous utilisez Gerrit , Gerrit lui-même devient le référentiel central (il possède des serveurs SSH et HTTP intégrés qui permettent aux utilisateurs d'interagir avec eux de la même manière qu'ils le sont déjà). Lorsque vous utilisez Gerrit, le flux de travail devient:

1. Le développeur apporte des modifications sur n'importe quelle branche, s'engage localement.
2. Le développeur transmet ces modifications à Gerrit.
3. Gerrit crée des éléments de révision pour les autres utilisateurs.
4. Les pairs révisent le code, font des commentaires et acceptent ou refusent la validation.
5. Lorsque le Commit est accepté, alors Gerrit fait ces changements disponibles pour les autres à tirer de la branche.

Lors de l'utilisation d'un référentiel central, les autres développeurs peuvent voir les modifications soumises après l'étape 2. Gerrit introduit le flux de travail de révision du code. Les autres développeurs ne voient donc que les modifications soumises après l'étape 5.

Cela fonctionne bien avec git-flow (ou tout autre système de branches) car Gerrit prend en charge la révision des modifications apportées à toutes les branches.

Voici une autre suggestion.

1. Exécutez le processus de flux Git habituel pour créer une fonctionnalité , mais ne la terminez pas et ne la fusionnez pas.
2. Créez une demande d'extraction , mais ne la fusionnez pas. Attendez que l'approbateur laisse un commentaire. Le commentaire est la marque d'approbation.
3. Faites la finition git flow . (L'approbateur ou le développeur peut le faire, en fonction de l'accord de l'équipe.) La demande d'extraction sera marquée comme étant fusionnée sur github. Vous devez toujours supprimer la branche d'origine.