Zusammenarbeiten über Pull Requests

Abgeschlossen

Mithilfe von Pull Requests können Sie andere Benutzer*innen über Änderungen informieren, die Sie per Push an ein GitHub-Repository übertragen haben.

Sobald ein Pull Request gesendet wurde, können interessierte Parteien den Satz von Änderungen überprüfen, mögliche Änderungen diskutieren und sogar Nachfasscommits pushen, wenn erforderlich.

Pull Requests werden häufig von Teams und Organisationen verwendet, die für ihre Zusammenarbeit das Shared Repository Model nutzen.

Alle teilen sich ein einzelnes Repository, und Topic-Branches werden verwendet, um Features zu entwickeln und Änderungen zu isolieren.

Viele Open-Source-Projekte auf GitHub verwenden Pull Requests, um Änderungen von Mitwirkenden zu verwalten.

Sie bieten eine Möglichkeit, Projektbetreuer über vorgenommene Änderungen zu benachrichtigen.

Außerdem können ein Code Review und eine allgemeine Diskussion über eine Reihe von Änderungen begonnen werden, bevor sie in den Mainbranch gemergt werden.

Pull Requests kombinieren den Review- und Mergevorgang Ihres Codes in einem einzelnen Kollaborationsprozess.

Wenn Sie mit der Behebung eines Fehlers oder mit einem neuen Feature im Branch fertig sind, erstellen Sie einen neuen Pull Request.

Fügen Sie dem Pull Request die Teammitglieder hinzu, damit sie Ihre Änderungen überprüfen und darüber abstimmen können.

Verwenden Sie Pull Requests zum Überprüfen von laufenden Arbeiten und für frühzeitiges Feedback zu Änderungen.

Es besteht keine Verpflichtung, die Änderungen mergen, da der Besitzer den Pull Request jederzeit verwerfen kann.

Code überprüfen lassen

Mit dem in einem Pull Request durchgeführten Code Review sollen nicht nur Fehler gefunden werden – damit befassen Sie sich in Ihren Tests.

Ein guter Code Review fängt weniger offensichtliche Probleme ab, die später zu kostspieligen Problemen führen können.

Code Reviews tragen zum Schutz Ihres Teams vor fehlerhaften Merges und fehlerhaften Builds bei, die seine Produktivität beeinträchtigen.

Im Review werden diese Probleme vor dem Merge abgefangen und Ihre wesentlichen Branches vor unerwünschten Änderungen geschützt.

Setzen Sie für Ihre Code Reviews eine Vielzahl von Reviewern ein, und sorgen Sie so dafür, dass sie gegenseitig von Fachwissen profitieren und Strategien zur Problemlösung verbreitet werden.

Durch die Weitergabe von Fähigkeiten und Wissen wird Ihr Team stabiler und resilienter.

Geben Sie großartiges Feedback

Qualitativ hochwertige Reviews beginnen mit qualitativ hochwertigem Feedback. Folgende Aspekte spielen für großartiges Feedback in einem Pull Request eine Schlüsselrolle:

• Bitten Sie die richtigen Personen, den Pull Request zu überprüfen.
• Stellen Sie sicher, dass die Reviewer wissen, was der Code macht.
• Geben Sie umsetzbares, positives Feedback.
• Antworten Sie umgehend auf Kommentare.

Stellen Sie beim Zuweisen von Reviewern zu Ihrem Pull Request sicher, dass Sie die richtige Gruppe von Reviewern auswählen.

Sie möchten Reviewer, die wissen, wie Ihr Code funktioniert, und versuchen, Entwickler einzubringen, die in anderen Bereichen arbeiten, um ihre Ideen zu teilen.

Wer kann außerdem Ihre Änderungen klar beschreiben und Ihren Code erstellen, in dem Ihre Korrektur oder Ihr Feature ausgeführt wird?

Reviewer sollten versuchen, Feedback zu Änderungen zu geben, mit denen sie nicht einverstanden sind. Identifizieren Sie das Problem, und schlagen Sie vor, was Sie im konkreten Fall anders machen würden.

Dieses Feedback hat eine klare Absicht und ist für den Besitzer des Pull Requests leicht verständlich.

Der Besitzer des Pull Requests sollte auf die Kommentare antworten, den Vorschlag annehmen oder erläutern, warum die vorgeschlagene Änderung nicht ideal ist.

Manchmal ist ein Vorschlag gut, aber die Änderungen liegen außerhalb des Bereichs des Pull Requests.

Nutzen Sie diese Vorschläge, und erstellen Sie neue Arbeitselemente und Featurebranches getrennt vom Pull Request, um diese Änderungen vorzunehmen.

Schützen von Branches mit Richtlinien

Ihre Repositorys enthalten in der Regel einen oder mehrere Branches, darunter auch den Main Branch, die aufgrund ihrer Kritikalität besonders geschützt werden müssen. Azure Repos bieten mehrere richtlinienbasierte Mechanismen, deren Implementierung Sie in Betracht ziehen sollten, um dieses Ziel zu erreichen.

Die Grundvoraussetzung für diese Mechanismen ist die Anwendung von Einschränkungen auf Pull Requests. Sie können z. B. bestimmte Richtlinien für die Code Review durchsetzen, wie beispielsweise die Forderung nach einer Mindestanzahl von Genehmigungen durch bestimmte Prüferinnen und Prüfer, bevor ein Pull Request zusammengeführt werden kann. Die Nutzung des kollektiven Fachwissens wird die Qualität und Zuverlässigkeit von Codeänderungen verbessern.

Ziehen Sie außerdem in Erwägung, die Richtlinie „Prüfung auf verknüpfte Arbeitselemente“ einzuführen. Dadurch wird sichergestellt, dass jeder Pull Request mit einem Arbeitselement verknüpft ist, was den Kontext und die Rückverfolgbarkeit fördert. Die Richtlinie zur Überprüfung der Auflösung von Kommentaren stellt sicher, dass alle Code Review-Kommentare vor dem Zusammenführen des Pull Request bearbeitet werden.

Richtlinien in Bezug auf die automatische Codeanalyse, Tests und Complianceprüfungen bestätigen, dass Änderungen den vordefinierten Standards vor der Integration entsprechen. Die Einschränkungen für Zusammenführungsarten helfen dabei, den Branch-Verlauf zu kontrollieren. So haben Sie beispielsweise die Möglichkeit, nur Fast-Forward- und Squashmerges zuzulassen.

Es ist auch möglich, sauberen Builds neuer Codeversionen zuzuweisen, bevor sie in die kritischen Verzweigungen zusammengeführt werden können. Dadurch wird sichergestellt, dass die zusammengeführten Änderungen keine Buildfehler oder Regressionsprobleme verursachen. Statusüberprüfungen können verwendet werden, um den Abschluss von Pull Requests von Signalen abhängig zu machen, die von externen Diensten generiert werden. Beispielsweise können solche Signale von Azure Pipelines generiert werden, die automatisierte Tests und Codeanalyse ausführen.

Alle Branches, die erforderliche Richtlinien konfiguriert haben, blockieren automatisch den direkten Push, und erzwingen effektiv Pull Requests für alle Änderungen. Darüber hinaus können solche Branches nicht gelöscht werden.