WERBEPLATZ VERFÜGBAR · PARTNERSCHAFTEN WILLKOMMEN

Wie Entwicklungsteams GitHub Copilot auf GitHub.com für PR-Zusammenfassungen und Code-Reviews einsetzen

365Finds Editorial
11.430 Wiki-Artikel erfasst

365 Wiki mit deiner KI nutzen

Kopiere den Prompt unten, füge ihn in deine gewohnte KI ein und stelle direkt deine Frage.

Vollständigen Skill herunterladen

Probiere es zuerst mit dem Prompt aus. Wenn du 365 Wiki häufig nutzt, installiere den vollständigen 365Wiki Skill, damit du ihn nicht jedes Mal einfügen musst. Ohne bevorzugte KI funktionieren auch die Webversionen von Gemini oder Microsoft Copilot.

Code-Reviews bei Pull Requests (PRs) zählen zu den wichtigsten Qualitätskontrollen in der Softwareentwicklung, entwickeln sich in der Praxis jedoch häufig zu einem zentralen Engpass. Entwickler verwenden wertvolle Arbeitszeit darauf, Änderungen manuell zusammenzufassen, oder hinterlassen spärliche Beschreibungen, die den Reviewern das Verständnis erschweren. Gleichzeitig verlieren überlastete Reviewer viel Zeit damit, oberflächliche Syntaxfehler, Formatierungsfragen oder fehlende Null-Prüfungen aufzuspüren, anstatt die Systemarchitektur und kritische Randbedingungen gründlich zu prüfen.

GitHub Copilot auf der Weboberfläche von GitHub.com setzt an beiden Enden dieses Problems an. Durch die Kombination aus KI-gestützten PR-Zusammenfassungen (PR Summaries) und automatisierten Code-Prüfungen (Copilot Code Review) können Teams den Überprüfungszyklus drastisch beschleunigen, die Dokumentationsqualität vereinheitlichen und Senior-Entwicklern den Raum geben, sich auf komplexe Architekturentscheidungen zu konzentrieren.


Auf einen Blick: Zwei komplementäre Review-Werkzeuge

Auf GitHub.com stellt GitHub Copilot zwei aufeinander abgestimmte Werkzeuge für den Pull-Request-Lebenszyklus bereit:

FunktionHauptnutzerAuslöserAusgabeformatNutzen für das Team
Copilot PR-Zusammenfassungen (PR Summaries)PR-Ersteller (Author)Auf Knopfdruck im Beschreibungs- oder KommentarfeldÜbersichtlicher Prosatext plus verlinkte Liste geänderter DateienBeseitigt undokumentierte PRs; ermöglicht Reviewern schnelles Erfassen des Kontexts
Copilot Code-Review (Code Review)Reviewer / TeamleitungManuell in der Seitenleiste angefordert oder per Ruleset automatisiertInline-Kommentare mit Schweregraden (High, Medium, Low) und 1-Klick-Code-VorschlägenErkennt Bugs und Sicherheitslücken in ca. 30 Sekunden; entlastet von mechanischer Fehlersuche

Diese Werkzeuge ersetzen menschliche Reviewer nicht. Sie übernehmen die Vorverarbeitung von Diffs und das Auffinden routinemäßiger Mängel, damit sich der fachliche Austausch ganz auf Geschäftslogik und sauberes Softwaredesign konzentrieren kann.


1. Erstellen von PR-Zusammenfassungen auf GitHub.com

Sobald ein Pull Request eingereicht wird, müssen Reviewer wissen: Was wurde geändert, warum wurde es geändert und welche Dateien sollten zuerst geprüft werden? Copilot PR Summaries analysiert das gesamte Branch-Diff und erstellt in Sekunden eine strukturierte Übersicht.

Schritt-für-Schritt-Anleitung

  1. Erstellen Sie einen neuen Pull Request auf GitHub.com oder öffnen Sie einen bestehenden PR.
  2. Klicken Sie in das Beschreibungsfeld (Description) oder in das Kommentarfeld am Ende der Seite.
  3. Klicken Sie in der Formatierungsleiste des Textfelds auf das Copilot-Symbol und wählen Sie Summary.
  4. Warten Sie einen kurzen Moment, während Copilot die Diffs aller Commits im Branch auswertet.
  5. Überprüfen Sie den generierten Text, ergänzen Sie wichtige geschäftliche Hintergründe und klicken Sie auf Create pull request bzw. Kommentar aktualisieren.

[!TIP] Starten Sie die Generierung immer in einem leeren Beschreibungsfeld. Copilot baut die Zusammenfassung rein aus dem Diff auf und bezieht bereits vorhandenen Text im Eingabefeld nicht mit ein. Falls Sie bereits eigene Notizen verfasst haben, generieren Sie zuerst die Copilot-Zusammenfassung und fügen Sie Ihre Notizen anschließend darunter ein.

Aufbau der generierten Zusammenfassung

Eine standardmäßige Copilot-PR-Zusammenfassung besteht aus zwei Abschnitten:

Best Practice für Teams: Die Trennung von „Was“ und „Warum“

Da Copilot ausschließlich den Code-Diff liest, ist das Modell hervorragend darin zu erklären, was sich geändert hat und wie Komponenten miteinander interagieren. Copilot hat jedoch keinen Zugriff auf Produktanforderungsdokumente, Ticket-Diskussionen oder Architekturentscheidungen aus Team-Meetings.

Erfolgreiche Entwicklungsteams etablieren daher eine klare Arbeitsteilung:


2. Schnellere Code-Prüfung mit Copilot Code Review

Nachdem der Kontext geklärt ist, sorgt Copilot Code Review dafür, dass Mängel frühzeitig bereinigt werden, bevor Teamkollegen ihre Zeit investieren.

Auslösemodi: Manuell auf Abruf vs. automatisierte Rulesets

Teams können Copilot Code Review flexibel an ihre Arbeitsweise anpassen:

1. Manuelle Anforderung

Ähnlich wie bei menschlichen Kollegen kann Copilot jederzeit angefordert werden:

  1. Öffnen Sie den Pull Request auf GitHub.com.
  2. Suchen Sie in der rechten Seitenleiste unter Reviewers nach Copilot.
  3. Klicken Sie auf Request.
  4. In der Regel innerhalb von 30 Sekunden analysiert Copilot den Diff und veröffentlicht Kommentare.

2. Automatisierte Auslösung über Rulesets

Administratoren können Richtlinien auf Repository- oder Organisationsebene einrichten:

Prüftiefe wählen: Lite vs. Balanced

Copilot Code Review bietet zwei Analysestufen, um Laufzeit, Kosten und Prüftiefe abzustimmen:

Feedback auswerten und 1-Klick-Korrekturen nutzen

Die Rückmeldungen von Copilot sind darauf ausgelegt, Nacharbeiten sofort umzusetzen:

  1. Schweregrad-Einstufung: Hinweise werden mit High, Medium oder Low gekennzeichnet, sodass Teams kritische Sicherheitsrisiken vor kosmetischen Details priorisieren können.
  2. 1-Klick-Code-Vorschläge: Copilot fügt anwendbare Code-Diffs direkt in die Kommentare ein. Entwickler können diese einzeln übernehmen oder gebündelt als Commit committen.
  3. Delegation an den Cloud-Agenten (Fix with Copilot): Bei umfangreicheren Anpassungen genügt ein Klick auf Fix with Copilot. Der Copilot Cloud Agent erstellt eine temporäre Umgebung, nimmt die Änderungen vor, führt Linter aus und committet die Lösung direkt.
  4. Copilot-Freigaben (Copilot Approvals, Vorschau): Die Übersichtsbewertung signalisiert, ob der PR freigabereif ist. Bei entsprechender Konfiguration kann dies Branch-Protection-Regeln für unkritische Pfade erfüllen.

3. Review-Standards mit Custom Instructions und AGENTS.md steuern

Ohne projektbezogene Vorgaben kann KI-Feedback an den internen Standards eines Teams vorbeigehen. Über Konfigurationsdateien im Repository lässt sich Copilot präzise auf die eigenen Richtlinien abstimmen.

Anpassungsoptionen im Vergleich

KonfigurationsartSpeicherortBester EinsatzzweckGeltungsbereich
Copilot-Instruktionen.github/copilot-instructions.mdGlobale Review-Vorgaben, Stilregeln und Architekturprinzipien für CopilotGesamtes Repository
Pfadspezifische Instruktionen.github/instructions/**/*.instructions.mdDetaillierte Regeln für spezifische Verzeichnisse, Programmiersprachen oder ModuleNur passende Dateipfade
Gemeinsame Agent-RegelnAGENTS.md (Repository-Wurzel)Dauerhafte Entwicklungsvereinbarungen für alle KI-Tools und AgentenGesamtes Repository
Agent Skills.github/skills/code-review/Spezialisierte Workflows für Sicherheitsaudits oder LeistungsprüfungenBei gezieltem Aufruf

Praxisbeispiel: Repository-weite Review-Instruktionen

Durch Anlegen der Datei .github/copilot-instructions.md stellt das Team sicher, dass interne Absprachen eingehalten werden:

# Richtlinien für Code-Reviews

Beachte bei der Überprüfung von Pull Requests in diesem Repository folgende Grundsätze:
1. **Sicherheit**: Alle SQL-Abfragen müssen Parameter-Binding verwenden; dynamische String-Verkettungen sind unzulässig.
2. **Performance**: Achte streng auf N+1-Abfrageprobleme in ORM-Aufrufen.
3. **Fehlerbehandlung**: Asynchrone Funktionen müssen strukturierte Logs ausgeben; Exceptions dürfen nicht lautlos ignoriert werden.
4. **Code-Formatierung**: Ignoriere Formatierungsdetails, die Prettier automatisch behebt; konzentriere dich auf Zustandssicherheit und Randfälle.

[!NOTE] Copilot liest die Konfigurationsdateien aus dem Head-Branch des PR. Dadurch können Teams Regeländerungen direkt in einem Feature-Branch erproben, bevor sie in den Hauptzweig übernommen werden.


4. Der ideale Team-Workflow: Ein typischer Entwicklungszyklus

Erfolgreiche Entwicklungsteams etablieren einen klar strukturierten dreistufigen Review-Zyklus:

[ Entwickler pusht Branch ]
           │
           ▼
1. Draft-Phase & Selbstprüfung ──► Klick auf "Summary" zur automatischen Übersicht
           │                      Copilot-Review im Draft PR anfordern
           │                      High/Medium-Befunde per 1-Klick beheben
           ▼
2. Vorbereitung für Kollegen ────► Geschäftliches "Warum" ergänzen, PR auf "Ready" setzen
           │                      Menschlicher Reviewer erfasst Kontext in 30 Sekunden
           │                      Keine Ablenkung durch Syntaxfehler (bereits behoben)
           ▼
3. Menschliches Peer-Review ─────► Fokus auf Architektur, Domänenlogik und Stabilität
           │                      Copilot Chat auf Web für Detailfragen nutzen
           ▼
[ Erfolgreicher Merge in den Main-Branch ]

Phase 1: Vorabprüfung durch den Autor

Phase 2: Schnelle Orientierung für den Reviewer

Phase 3: Fundiertes Feedback und Freigabe


5. Lizenzierung, KI-Credits und Kostenkontrolle

Für die Einführung im Unternehmensumfeld sind Berechtigungen und Abrechnungsmodelle zu beachten:


6. Grenzen der Automatisierung und Verantwortung

Trotz der enormen Effizienzgewinne müssen Teams die Grenzen der KI klar definieren:

  1. Die Letztverantwortung liegt beim Menschen: Auch wenn ein KI-Vorschlag übernommen wurde, tragen der Autor und der freigebende Ingenieur die uneingeschränkte Verantwortung für Produktionsfehler.
  2. Kein Ersatz für Tests: Copilot Code Review findet nicht jeden Fehler. End-to-End-Tests, statische Sicherheitsanalysen (wie CodeQL) und die fachliche Validierung bleiben unverzichtbar.
  3. Sinnvoller Umgang mit False Positives: Weist Copilot auf Aspekte hin, die bewusst so entworfen wurden, sollten Entwickler den Hinweis sachlich verwerfen oder als gelöst markieren.
  4. Governance und Datenschutz: Stellen Sie sicher, dass Richtlinien zum Abgleich mit öffentlichem Code (Public Code Matches) und Firewall-Regeln den Unternehmensstandards entsprechen.

Fazit

GitHub Copilot auf GitHub.com verwandelt den Pull-Request-Prozess von einer zähen Pflichtaufgabe in einen produktiven, hochgradig fokussierten Ingenieursworkflow. Durch die Automatisierung von Zusammenfassungen und mechanischen Prüfungen gewinnen Entwickler wertvolle Zeit zurück – Zeit, die sie in robuste Architekturen und innovative Lösungen investieren können.

Referenzen