Warum Pull-Anforderungen verwenden, anstatt sie zusammenzuführen?

Was ist der Vorteil der Verwendung von Pull-Anforderungen, anstatt einfach eine Verzweigung ohne eine in Master zusammenzuführen? Besonders in einem Team, in dem alle Entwickler uneingeschränkten Zugriff auf Master haben.

Pull-Requests sorgen für Checks and Balances, auch wenn jeder zum Master pushen kann.

Der größte Vorteil ist, dass sie eine Möglichkeit zur Codeüberprüfung bieten. Die Person, die für die Durchführung des Pulls verantwortlich ist, kann den Code und die Tests einsehen und sicherstellen, dass sie alle Richtlinien der Organisation oder des Teams erfüllt. Es gibt auch andere Gründe für die Codeüberprüfung : Schulung, Auffinden von Fehlern oder Verbesserungen, Cross-Training des Teams auf dem System, um den Testern eine White-Box-Ansicht des Systems zu ermöglichen.

Wenn die Person, die den Pull ausführt, mit der Architektur des Systems vertraut ist, kann sie sicherstellen, dass die Änderungen mit der Architekturvision des Systems übereinstimmen, insbesondere wenn das gesamte Team möglicherweise nicht über die langfristige Vision verfügt.

Die Gewohnheit, Pull-Requests zu verwenden, kann Ihrem Team auch helfen, wenn Sie in Zukunft entscheiden, dass das gesamte Team keinen Zugriff auf Master haben sollte. Wenn Ihr Team größer wird und insbesondere wenn Sie Teammitglieder haben, die neu im Produkt und / oder neu in Git sind, kann es für die Produktintegrität sicherer sein, ihnen keinen Zugriff auf den Master zu gewähren.

Nachdem Sie sowohl Feature-Verzweigungen als auch Forks + Pull-Anforderungen durchgeführt haben, sind Pull-Anforderungen meines Erachtens von geringem Vorteil, wenn Sie sich alle im selben Team oder Unternehmen entwickeln

Sie bieten zwar einen guten Mechanismus und eine gute Schnittstelle für die Codeüberprüfung, erschweren und verlangsamen jedoch auch den gesamten Prozess, der zum Abschluss gebracht wird. Vor allem, wenn Sie viele kleine Features haben, die jeweils auf Überprüfung warten, zusammengeführt werden und dann alle anderen wieder mit dem Master zusammengeführt werden, um die Änderungen zu übernehmen .

Allerdings können Sie Anfragen zwischen Zweigen desselben Repos ziehen. Sie müssen nicht verzweigen oder unterschiedliche Berechtigungen haben.

Zusätzlich müssen Sie Ihre gesamte Methodik und Ihren Workflow berücksichtigen. Haben Sie auch ein Ticketsystem, ein CI, automatisierte Abnahmetests usw.? Bieten Ihre Codeüberprüfungen eine wichtige Einzelüberprüfung, bevor die Codes online gehen, oder handelt es sich nur um Stempelübungen, die durch andere Überprüfungen in Ihrem Workflow überflüssig werden?

Es gibt eine Beobachtung namens Conway's Law, die besagt:

Organisationen, die Systeme entwerfen ... sind gezwungen, Entwürfe zu erstellen, die Kopien der Kommunikationsstrukturen dieser Organisationen sind.

Was hat das mit Pull Requests zu tun? Pull-Anforderungen sind ein wichtiger Kommunikationskanal an einer kritischen Schnittstelle für Ihren Code. Sie bieten die Möglichkeit zur Überprüfung, zum automatisierten Testen und zur Verbesserung, bevor der Code in die nächsten Phasen des Testens und der Produktion übergeht, in denen es viel schwieriger ist, diese Änderungen rückgängig zu machen, und viel mehr Zeit für viel mehr Mitarbeiter verschwenden.

Ebenso empfiehlt das Conway-Gesetz, dass die Kommunikationskanäle Ihres Unternehmens die Architektur widerspiegeln sollten, die Sie erreichen möchten, wenn Sie eine Microservice-Architektur mit sauber getrennten Bereichen der autonomen Verantwortung und genau definierten Schnittstellen wünschen. Dies bedeutet, dass kleine Teams von 5 bis 10 Personen direkten Commit-Zugriff auf einen bestimmten Microservice haben sollten, und dass jeder außerhalb dieses Teams eine Pull-Anfrage durchlaufen muss. Dies stellt sicher, dass die Personen, die mit einem Mikroservice am besten vertraut sind, diesen überprüfen und beraten.

Wenn Sie eine große Organisation haben, zu der jeder direkten Zugriff hat, bereiten Sie Ihre Kommunikationskanäle mit dem geringsten Widerstand darauf vor, einen großen Ball von Schlammarchitektur zu produzieren.

Pull-Anfragen empfinden Sie nur dann als Belastung, wenn Sie keine Gegenleistung erbringen. Ich habe in Umgebungen gearbeitet, in denen ich eine Woche lang nichts machen kann, weil der Build immer kaputt ist, und ich habe in Umgebungen gearbeitet, in denen jemand eine Pull-Anfrage einreicht und ich sie nicht einmal überprüfen muss, weil sie kaputt sind Der CI-Build und ich sage Ihnen, sie sind jede Sekunde Mühe wert.

Karl Bielefeldt ist genau richtig. Ich würde hinzufügen: Es geht nur um Qualität.

Viele (die meisten?) Läden haben keine formalen Prozesse zur Steuerung der Entwicklung, was dazu führt, dass: "Ich habe in Umgebungen gearbeitet, in denen ich eine Woche lang nichts machen kann, weil der Build immer kaputt ist, und ich habe gearbeitet In Umgebungen, in denen jemand eine Pull-Anfrage sendet und ich sie nicht einmal überprüfen muss, weil er den CI-Build gebrochen hat, sind sie jede Sekunde Mühe wert. "

Es ist wirklich die Mühe wert.

Wir verwenden Pull-Requests für die Codeüberprüfung. Es sollte kein Code in den Hauptentwicklungszweig eingefügt werden (normalerweise "Entwickeln" in unserem Fall, aber manchmal "Master"), ohne eine Pull-Anfrage durchlaufen zu haben. Wir erzwingen dies nicht hart mit Repository-Kontrollen, aber das liegt daran, dass wir es nicht müssen - unsere Entwickler sind ausgereift genug, um den Prozess nicht zu missbrauchen.