Révision de code Gerrit ou modèle à fourche et tirage de Github?

64

Je commence un projet de logiciel qui sera développé par l'équipe ET la communauté. Auparavant, j’étais vendu sur gerrit, mais le modèle de demande d’achat et de retrait de Github semble désormais fournir presque plus d’outils, de moyens de visualisation des validations et de facilité d’utilisation.

Pour quelqu'un qui a au moins un peu d'expérience avec les deux, quels sont les avantages / inconvénients de chacun, et lequel serait le mieux pour un projet basé sur une équipe qui souhaite laisser la possibilité de développement communautaire?

git github forking gerrit utilisateur1366476
la source

Réponses:

84

La principale différence entre les flux de travail de Gerrit et de GitHub réside dans la modélisation des changements.

Dans Gerrit, chaque engagement est un changement autonome. Bien que Gerrit vous montre les relations entre les validations, les révisions sont effectuées validation par validation. Les équipes qui savent bien décomposer de gros changements en petits commits autonomes auront probablement plus de succès avec Gerrit. Cependant, étant donné que le modèle de Gerrit inclut des révisions successives d'un commit particulier, il encourage les workflows Git auxquels de nombreux développeurs ne sont pas habitués. commettre.

Dans Github, une demande d'extraction modélise une relation entre deux branches. Le flux de travail attendu sur Github consiste à valider une ou plusieurs modifications dans une branche de sujet (souvent dans une branche du référentiel, mais pas nécessairement) et à créer une demande d'extraction entre cette branche et la branche "en amont". Dans ce cas, ce qui est examiné est un ensemble d’engagements qui continue de croître au fur et à mesure de l’examen. Le résultat est un ensemble de modifications qui peuvent ensuite être fusionnées de manière atomique lorsqu'elles sont terminées. Les demandes d'extraction peuvent être efficaces pour suivre les modifications avec une portée plus grande pouvant être implémentée sur plusieurs validations. Les demandes d'extraction prennent également en charge les flux de travail SCM auxquels plus de développeurs sont habitués, par exemple en répondant à un commentaire de révision en soumettant un commit de suivi dans la même branche.

Un grand avantage en faveur de Github est le nombre de développeurs qui le connaissent bien par rapport à Gerrit. Gerrit peut être populaire auprès des utilisateurs assidus de Git, mais son utilisation sans frottement nécessite des connaissances git intermédiaires ou avancées, ainsi qu'une bonne tolérance à l'égard d'une courbe d'apprentissage abrupte.

L'avantage de Gerrit est une relation plus profonde avec Git. Les demandes d'extraction Github sont suffisamment éloignées du modèle de données standard de Git pour qu'il soit nécessaire d'utiliser l'interface utilisateur Web de Github ou son API propriétaire pour créer des demandes d'extraction. L'interface de Gerrit pour créer et mettre à jour les modifications est le protocole git lui-même.

Martin Atkins
la source
8
Merci Martin, c'est une réponse intéressante. Je voulais regarder Gerrit depuis un moment, mais je pense que je vais mettre ça de côté. Si cela incite à éditer l’histoire et à réduire les commits, je ne veux rien avoir à faire avec cela. * 8 '(
Mark Booth
15
Soyons clairs (j'utilise souvent Gerrit sur mon lieu de travail), ce que Martin dit ici: "Gerrit ... encourage les workflows Git ... tels que modifier un commit précédent et le repousser, ou écraser un nombre croissant de commits. ..into un seul commit "est tout à fait correct. Ma clarification est que le commentaire de @ MarkBooth sur "l'édition de l'historique" n'est pas ce que Martin a dit. La modification des commits (tant qu'elle est toujours sur Gerrit et qu'elle n'a pas encore été fusionnée avec origine / maître) n'entraîne pas "l'historique des modifications". En fait, ce flux de travail fonctionne très bien. La «mauvaise» édition de l'histoire évoquée par Mark Booth consiste à repousser les historiques modifiés vers l'origine / le maître.
Likethesky
2
Merci pour la clarification @likethesky, mais j’ai une interprétation un peu plus littérale de «l’historique des modifications» et, en ce qui me concerne, tout ce qui aboutit à des ensembles de modifications dont le contenu n’a pas été explicitement validé est «l’historique des modifications». Je réalise cependant que cette interprétation est plutôt draconienne et que peu d’autres y adhèrent. * 8 ')
Mark Booth le
2
C'est suffisant. :-) Pas sûr de comprendre ce que vous entendez par "changesets qui contiennent du contenu que vous n'avez pas explicitement engagé", donc pls. élaborée ... Je suppose que vous ne dites pas que vous ne commettez jamais de commises temporaires (locales ou partagées par des membres de l’équipe via des branches distantes), comme, squash / amende plus utile qui dit, "Issue 123: XYZ refactorisé pour augmenter la résilience et la facilité de mise à l'échelle horizontale" comme message de validation final pour ce travail. Quoi qu'il en soit, vous pouvez bien sûr choisir d'utiliser git de manière à vous rendre heureux!
Likethesky
7
C'est une réponse fantastique. Pour ajouter, j'ai constaté que les demandes d'extraction de GitHub génèrent des commits plus petits et plus itératifs et aboutissent souvent à un journal git beaucoup plus descriptif qui indique non seulement le produit du travail, mais également son processus. La révision de code de Gerrit favorise un historique beaucoup plus propre du référentiel (il y a très très peu de commits de fusion réels) avec des commits plus grands et plus polis.
tophyr