Comment mettre en place une revue de code avec Gitlab?

85

Comment mettre en place une revue de code à l'aide de Gitlab? Je le vois répertorié comme une fonctionnalité sur le site Web de Gitlab, mais je n'arrive pas à trouver des instructions sur la façon d'en configurer une (d'ailleurs, tout lien vers un manuel d'utilisation de Gitlab serait le plus apprécié).

Certaines de mes recherches ont indiqué que les «demandes de fusion» sont la voie à suivre ... mais je les trouve limitantes. Une demande de fusion émise montre tous les commits entre une branche et l'autre. Il semble que je ne puisse voir que les différences générées pour chaque commit individuel. Par exemple, disons que j'ai un fichier que je souhaite examiner. C'est un nouveau fichier mais j'y ai soumis des modifications sur 10 commits sur une branche de développement. Si j'émets une demande de fusion pour cette branche de développement à partir de l'intégration, je vois 10 commits dont chacun montre les modifications incrémentielles apportées au fichier ... Je veux revoir le tout. C'est nouveau!

Suis-je en train d'aboyer le mauvais arbre ici? Existe-t-il un outil de révision de code que je peux utiliser dans GitLab, ou les demandes de fusion sont-elles la voie à suivre, et si elles sont, est-ce que je les utilise de manière incorrecte? Quelle est la meilleure façon de configurer une révision de code appropriée ici?

djc6535
la source
1
GitLab 6.4 et sa vue de comparaison côte à côte peuvent aider à la révision du code: voir ma réponse ci
VonC
Avec GitLab 13.1 (juin 2020), vous disposez désormais des révisions des demandes de fusion. Voir ma réponse modifiée ci
VonC

Réponses:

24

Remarque: depuis GitLab 6.4, une vue de comparaison côte à côte est disponible: voir " pull request 5308 ".

(Juillet 2013)Il n'y a cependant pas encore de possibilité de commenter chaque ligne, uniquement au niveau du fichier.
Daniel Sokolowski mentionne dans les commentaires que les commentaires par ligne sont désormais pris en charge (09/2014):

Les membres de votre équipe peuvent commenter la demande de fusion en général ou sur des lignes spécifiques avec des commentaires de ligne.

Cela peut toujours aider pour l'activité de révision de code.

https://f.cloud.github.com/assets/4224518/1558702/e0fe633a-4fa3-11e3-9388-3f3e445cb6d4.png


6 ans plus tard, pour GitLab 13.1 (juin 2020) :

Les révisions des demandes de fusion ont été déplacées vers Core

Initialement introduite dans GitLab 11.4 en tant que fonctionnalité GitLab Premium, les révisions des demandes de fusion permettent aux réviseurs de demandes de fusion de:

  • soumettre plusieurs commentaires à la fois,
  • réduire le bruit de notification pour l'auteur de la demande de fusion, et
  • permettant un processus d'examen plus cohérent et rationalisé.

https://about.gitlab.com/images/13_1/batch_comments.png

Depuis son introduction, nous avons réévalué sa place dans notre modèle de tarification basé sur l'acheteur et, dans le cadre de la 13.1, nous sommes ravis d'annoncer que cette fonctionnalité a maintenant été déplacée vers GitLab Core.

Voir la documentation et le problème

VonC
la source
Les commentaires par ligne sont désormais pris en charge: "Les membres de votre équipe peuvent commenter la demande de fusion en général ou sur des lignes spécifiques avec des commentaires de ligne." ( about.gitlab.com/2014/09/29/gitlab-flow )
Daniel Sokolowski
1
@DanielSokolowski Super! J'ai inclus votre commentaire dans la réponse pour plus de visibilité.
VonC
9

Je fais des révisions de code dans Gitlab depuis plus de deux mois sans presque aucune friction. J'ai configuré rss2email pour envoyer des notifications par e-mail à chaque fois qu'un développeur envoie de nouveaux commits. Ensuite, j'utilise la fonction de commentaire de Gitlab pour les commits afin de faire des commentaires sur le code poussé.

Malheureusement, Gitlab n'autorise pas les commentaires sur les fichiers lui-même, uniquement dans les commits (tout comme Github, je suppose). Chaque fois que je me trouve dans une situation où j'ai besoin de commenter quelque chose que j'ai manqué dans un commit précédent, j'utilise l'outil de blâme pour trouver le commit qui a introduit / modifié la section de code à commenter.

C'est loin d'être parfait, mais cela fonctionne bien jusqu'à présent.

Herberth Amaral
la source
1
Au lieu de rss2email, on pourrait utiliser les notifications Gitlab pour être notifié des pushs.
vadipp
J'ai le même problème / solution de contournement. Je pense que ce serait une fonctionnalité intéressante que vous puissiez ajouter un commentaire au bon commit blâmant une ligne particulière dans la vue diff ou fichier (je veux dire à partir de l'interface Web parcourant les fichiers ou les diffs, sans rejeter le blâme).
AlejandroVD
2

Vous pouvez voir le code soumis dans la demande de fusion pour un autre référentiel ou dans le référentiel actuel.
exemple http://demo.gitlab.com/diaspora/diaspora/commits/master

Ensuite, vous pouvez ajouter des commentaires aux changements de fichiers validés (bouton Reply) ou à l'ensemble du commit

exemple http://demo.gitlab.com/diaspora/diaspora/commit/42f47626890218a180870bc3f44ec57625b0779c

La communication qui en résulte est la révision du code . Cependant, je recommande personnellement de faire une révision du code sur un PC avec une communication en face à face chaque fois que possible, et d'utiliser des outils pour enregistrer les résultats ou lorsque plus de formalité est nécessaire.

Pour une revue de fichier qui a beaucoup de commits, par exemple http://demo.gitlab.com/diaspora/diaspora/blame/master/README.md regardez-la en utilisant blamepour comprendre qui a fait quoi. Cependant, dans cette vue, il n'y a pas d'option pour communiquer et ajouter des commentaires. Je recommanderais simplement d'ajouter des modifications en tant que commentaires dans ce cas.

Paul Verest
la source
7
J'obtiens un 404 pour le premier, le deuxième et le dernier lien de votre réponse.
Bryan Oakley
1
Comme il est dit sur la page d'accueil, demo.gitlab.com "EST UNE SANDBOX - il est réinitialisé toutes les heures" donc tous les exemples ont été effacés. Ce n'est pas un bon véhicule pour les exemples.
Uriah Blatherwick
Oui, veuillez reconsidérer sa configuration avec des exemples appropriés. Votre réponse semble être un conseil généralement solide.
données du
0

Oui. Les demandes de fusion sont la manière dont les évaluations par les pairs sont effectuées.

Il devrait y avoir un onglet 'diff' qui affichera les changements de tous les commits (mentionnés ici: http://youtu.be/DyAX8ws5OIc?t=3m2s ).

La vidéo explique également bien comment elle peut être utilisée pour l'examen par les pairs.

oignon
la source
0

Le cas d'utilisation normal des revues de code est de revoir le code sur une branche avant de fusionner avec master ou similaire. J'ai une situation où j'ai développé un projet et je veux que tout le code soit revu par tous les membres de l'équipe.

Ce que j'ai fait était:

Vérifiez le premier commit, apportez-y une modification, validez et poussez

git co -b FIRST_COMMIT eb67f06c2b3222c0219214b176c41922bc454881
vi README.md
git add README.md
git ci -m "First commit modified so can get full diff against it"
git push --set-upstream origin FIRST-COMMIT

Récupérez le dernier commit, apportez-y une modification, validez et poussez

git co -b master
vi README.md
git add README.md
git ci -m "Last commit modified so can get full diff against it"
git push --set-upstream origin LAST-COMMIT

Sur GitLab / GitHub, créez une pull request

  • Il s'agit d'une fusion de LAST_COMMIT à FIRST_COMMIT

Travaille pour moi!

HankCa
la source
Cela ne vous laisse-t-il pas deux branches "indésirables" dans le référentiel, et aucun suivi des commentaires dans la branche principale? Si les commentaires nécessitent des modifications de code, les fusionnez-vous ensuite dans le master?
user2084572
Oui, il y aura des branches FIRST_COMMIT et LAST_COMMIT faciles à supprimer ( git br --delete --force origin FIRST_COMMIT LAST_COMMIT; git br --delete --force FIRST_COMMIT LAST_COMMIT). Vous pouvez utiliser un autre maître de branchement pour contenir les modifications apportées, ou créer des problèmes distincts manuellement. Et plus tard, créez une ou plusieurs branches (par exemple, une par numéro) s'il y a trop de commentaires.
HankCa