web-dev-qa-db-fra.com

revue de code avec git-flow et github

Avec git et github réguliers, je peux faire une revue de code en créant simplement une requête pull de la branche de fonctionnalité sur laquelle je travaille vers la branche master. Comment pourrais-je faire des revues de code avec git-flow? Avec un flux de travail comme "la fin de la fonctionnalité de flux git", je ne sais pas où la révision du code se produit réellement et comment git-flow ou git peut faciliter cette révision.

code-qualitygitcode-reviewsgithubgitflow
43
AdamT

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

Le problème que nous avons est avec git feature finish, car il fusionne la branche dans le développement, alors que nous voulons qu'une demande de pull soit envoyée et (c'est important) fusionné par le réviseur, pas 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 pull (en utilisant github)
  3. L'examen a lieu, avec des engagements supplémentaires potentiels
  4. La demande d'extraction est fusionnée en utilisant GitHub par le réviseur.
  5. Il n'y a pas de finition de fonctionnalité git flow (car la branche est déjà fusionnée)

Ceci est cohérent avec notre pratique, avec l'inconvénient d'exiger de supprimer la branche nous-mêmes (car nous ne git flow finish). Notre prochaine étape sera probablement de réimplémenter certaines parties de git flow (car il s'agit principalement de chaîner les commandes git) pour en tenir compte (avoir la partie "nettoyage" de la finition, sans la fusion).

29
Martin

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

  1. Créez une branche d'entité: git flow feature start module_1
  2. Le code est mis à jour sur la branche de fonctionnalité
  3. Lorsque les modifications sont validées, elles sont transmises à GitHub (ou une fois à la fin si vous préférez)
  4. Une fois la fonctionnalité terminée, une requête d'extraction est ouverte dans GitHub comparant develop et la branche de fonctionnalité module_1
  5. L'équipe examine la demande d'extraction et fait des commentaires
  6. Toutes les modifications de la demande d'extraction sont apportées à la branche de fonctionnalité
  7. Une fois que toutes les modifications sont incorporées dans la branche de fonctionnalité, la branche de fonctionnalité est terminée: git flow feature finish module_1
  8. La branche develop est poussée vers GitHub (GitHub marquera automatiquement la demande de tirage comme fermée/fusionnée lorsque cela se produit)

Normalement, tout ce processus est effectué par l'auteur d'origine, mais ce n'est pas obligatoire. Tout membre de notre équipe peut intervenir et reprendre ce processus à tout moment. Tout ce qu'ils ont à faire est de retirer la branche de fonctionnalité et de poursuivre le processus. Qui dirige jamais git flow feature finish module_1 aura le luxe que sa branche de fonctionnalité locale soit supprimée, mais toute autre personne ayant vérifié la branche doit le faire manuellement si elle souhaite utiliser quelque chose comme git branch -D feature/module_1.

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

17
brainimus

Voici une autre suggestion.

  1. Faites le processus git flow normal pour créer une fonctionnalité, mais ne le terminez pas ou ne le fusionnez pas.
  2. Créez une demande de tirage, mais ne la fusionnez pas. Attendez que l'approbateur laisse un commentaire. Le commentaire est la marque d'approbation.
  3. Faites le git flow finish. (L'approbateur ou le développeur peuvent le faire, selon l'accord de l'équipe.) La demande d'extraction sera marquée comme fusionnée sur github. Vous devez toujours supprimer la branche sur Origin.
4
Peet Brits

Si vous effectuez des révisions de code, je suppose que vous disposez d'un référentiel central contenant le code "officiel". Les développeurs tirent 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 lui 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 applique ces modifications à Gerrit.
  3. Gerrit crée des éléments de révision pour que d'autres puissent les réviser.
  4. Les pairs examinent le code, font des commentaires et acceptent ou rejettent la validation.
  5. Lorsque le commit est accepté, puis Gerrit rend ces modifications disponibles pour que d'autres puissent les retirer 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, et les autres développeurs ne voient donc les modifications soumises qu'après l'étape 5.

Cela fonctionne bien avec git-flow (ou tout autre schéma de branchement) car Gerrit prend en charge l'examen des modifications apportées sur n'importe quelle branche.

3
Greg Hewgill