Gerrit Code Review oder Github's Gabel und Ziehmodell?

Ich starte ein Softwareprojekt, das von einem Team UND einer Community entwickelt wird. Früher wurde ich auf Gerrit verkauft, aber jetzt scheint Githubs Gabel- und Pull-Anforderungsmodell mehr Tools, Möglichkeiten zur Visualisierung von Commits und Benutzerfreundlichkeit zu bieten.

Für jemanden, der zumindest ein wenig Erfahrung mit beidem hat, was sind die Vor- / Nachteile von jedem, und was wäre besser für ein teambasiertes Projekt, das die Möglichkeit zur Community-Entwicklung offen lassen möchte?

— user1366476
quelle

Der Hauptunterschied zwischen Gerrits und GitHubs Workflows besteht darin, wie Änderungen modelliert werden.

Bei Gerrit ist jedes Commit eine Veränderung, die für sich steht. Obwohl Gerrit Ihnen die Beziehungen zwischen Commits zeigt, werden Überprüfungen auf Commit-Basis durchgeführt. Teams, die große Veränderungen gut in kleine, in sich geschlossene Commits aufteilen können, werden mit Gerrit wahrscheinlich mehr Erfolg haben. Da Gerrits Modell jedoch sukzessive Überarbeitungen eines bestimmten Commits enthält, werden Git-Workflows unterstützt, an die viele Entwickler nicht gewöhnt sind, z verpflichten.

In Github modelliert eine Pull-Anfrage eine Beziehung zwischen zwei Zweigen. Der erwartete Arbeitsablauf bei Github besteht darin, eine oder mehrere Änderungen in einen Zweig eines Themas zu übertragen (häufig in einem Zweig des Repositorys, aber nicht unbedingt) und eine Pull-Anforderung zwischen diesem Zweig und dem Zweig "Upstream" zu erstellen. In diesem Fall wird eine Reihe von Commits überprüft, die mit fortschreitender Überprüfung weiter zunehmen. Das Ergebnis ist eine Reihe von Änderungen, die nach Abschluss der Änderungen atomar zusammengeführt werden können. Pull-Anforderungen können Änderungen mit einem größeren Bereich, der über mehrere Commits implementiert werden kann, effektiv nachverfolgen. Pull-Anforderungen unterstützen auch SCM-Workflows, an die sich immer mehr Entwickler gewöhnt haben, z. B. die Beantwortung eines Überprüfungskommentars durch Senden eines Follow-up-Commits in derselben Zweigstelle.

Ein großer Vorteil für Github ist die Anzahl der Entwickler, die im Vergleich zu Gerrit damit vertraut sind. Gerrit kann bei Git-Power-Usern beliebt sein, aber die reibungslose Verwendung erfordert mittlere oder fortgeschrittene Git-Kenntnisse und die Toleranz einer steilen Lernkurve.

Gerrits Vorteil ist eine tiefere Beziehung zu Git. Github Pull Requests sind weit genug vom Standarddatenmodell von Git entfernt, dass man entweder die Web-Benutzeroberfläche von Github oder die proprietäre API verwenden muss, um Pull Requests zu erstellen. Gerrits Schnittstelle zum Erstellen und Aktualisieren von Änderungen ist das Git-Protokoll selbst.

— Martin Atkins
quelle

Danke Martin, das ist eine interessante Antwort. Ich habe vorgehabt, Gerrit eine Weile anzusehen, aber ich denke, ich werde das zurückstellen. Wenn es die Bearbeitung des Verlaufs und das Zusammendrücken von Verpflichtungen fördert, möchte ich nichts damit zu tun haben. * 8 '(

— Mark Booth

Um ganz klar zu sein (ich benutze Gerrit oft an meinem Arbeitsplatz), was Martin hier sagt: "Gerrit ... ermutigt Git-Workflows ... wie das Ändern eines früheren Commits und das erneute Drücken des Commits oder das Unterdrücken einer wachsenden Anzahl von Commits. ..in a single commit "ist genau richtig. Meine Klarstellung ist, dass der Kommentar von @ MarkBooth zur "Bearbeitung der Geschichte" nicht das ist, was Martin gesagt hat. Das Ändern von Commits (solange Gerrit noch aktiv ist und noch nicht mit Origin / Master zusammengeführt wurde) beinhaltet kein "Bearbeiten des Verlaufs". Tatsächlich funktioniert dieser Workflow hervorragend. Die "schlechte" Bearbeitung der Historie, auf die sich Mark Booth bezieht, drückt die bearbeiteten Historien erneut auf Origin / Master.

— Likethesky

Vielen Dank für die Klarstellung @likethesky, aber ich habe eine eher wörtliche Interpretation von "Bearbeitungsverlauf", und was mich betrifft, ist alles, was zu Änderungssätzen führt, die Inhalte enthalten, die Sie nicht explizit festgeschrieben haben, "Bearbeitungsverlauf". Mir ist jedoch klar, dass dies eine ziemlich drakonische Interpretation ist, an die sich nur wenige halten. * 8 ')

— Mark Booth

Fair genug. :-) Ich verstehe nicht, was Sie unter "Änderungssets, die Inhalte enthalten, die Sie nicht explizit festgelegt haben" verstehen. Ich gehe davon aus, dass Sie nicht sagen, dass Sie niemals temporäre (lokale oder von Teammitgliedern über entfernte Zweige geteilte) Commits wie "WIP: Dies versucht, das von uns diskutierte Arch-Problem zu lösen", gefolgt von einem Weitere hilfreiche Änderungen: "Problem 123: Überarbeitetes XYZ, um die Ausfallsicherheit zu erhöhen und die horizontale Skalierung zu vereinfachen". Aber natürlich können Sie git auf jede Weise verwenden, die Sie glücklich macht!

— Likethesky

Das ist eine fantastische Antwort. Außerdem habe ich festgestellt, dass die Pull-Anforderungen von GitHub zu kleineren, iterativeren Commits führen und häufig zu einem viel aussagekräftigeren Git-Protokoll führen, das nicht nur das Arbeitsprodukt, sondern auch den Arbeitsprozess anzeigt. Gerrits Code-Review sorgt für einen saubereren Repository-Verlauf (es gibt sehr, sehr wenige aktuelle Merge-Commits) mit größeren, ausgefeilteren Commits.

— Tophyr