Bereitstellen von gestapelten Pullanforderungen an Ihre Organisation

Mit gestapelten Pullanforderungen können Entwickler große Änderungen in eine Kette kleiner, fokussierter Pullanforderungen unterteilen, die aufeinander aufbauen. Dieser Ansatz kann Ihrer Organisation helfen, die Qualität zu überprüfen, da Entwickler mehr Code erstellen, einschließlich mit Copilot und anderen Codierungs-Agents.

Gestapelte Pullanforderungen erfordern keine Einrichtung oder Aktivierung. Wenn Ihr Team bereits Pullanforderungen verwendet, können sie heute einen Stapel erstellen. Die nachstehenden Schritte helfen Ihnen, Ihre vorhandenen Steuerelemente vorzubereiten und einen reibungslosen Rollout zu unterstützen und kein Feature zu aktivieren.

In diesem Lernprogramm können Sie entscheiden, ob gestapelte Pullanforderungen für Ihre Organisation geeignet sind, sicherstellen, dass die Grundlagen vorhanden sind, den Workflow testen, die Einführung unterstützen und programmgesteuerte Tools aktualisieren. Ein grundlegendes Verständnis von gestapelten Pullanforderungen finden Sie unter Informationen zu gestapelten Pullanforderungen.

1. Entscheiden Sie, ob gestapelte Pullanforderungen die richtige Passform sind.

Verwenden Sie diese schnelle Selbstüberprüfung, bevor Sie in ein Rollout investieren:

• Produzieren Ihre Teams ein hohes Codevolumen, entweder selbst oder mit oder mit Copilot anderen Codierungs-Agents?
• Arbeiten Ihre Teams an großen Features, insbesondere innerhalb von Monorepos, die schwer in unabhängige Pullanforderungen aufgeteilt werden können?

Wenn entweder Ihre Teams beschrieben werden, können gestapelte Pullanforderungen ihnen helfen, abhängige Änderungen in kleineren Einheiten zu übermitteln, ohne auf jede Pullanforderung zu warten, bevor sie mit dem nächsten zusammenführen, solange ihre Arbeit einer Einschränkung entspricht: Jede Pullanforderung in einem Stapel muss sich im selben Repository befinden, nach einer einzelnen linearen Verzweigungskette. Stapel können keine Forks oder Verzweigungsstrukturen enthalten, sodass Teams, die stark auf Forks für Beiträge angewiesen sind, diese Beiträge vorerst außerhalb von Stapeln behalten sollten.

2. Stellen Sie sicher, dass die Grundlagen vorhanden sind

Jede Pullanforderung in einem Stapel wird anhand der Basis des Stapels (in der Regel main) und nicht anhand der Verzweigung ausgewertet, auf die sie direkt ausgerichtet ist. Ihre vorhandenen Branch-Schutzregeln oder Rulesets und CI-Workflows gelten automatisch:

• Erforderliche Überprüfungen, erforderliche Statusprüfungen und CODEOWNERS werden alle für jede Pullanforderung im Stapel gegen den Basiszweig des Stapels erzwungen.
• Ein GitHub Actions Workflow, der für Ereignisse ausgelöst wird, die auf pull_request den Standardzweig eines Repositorys abzielen, wird für jede Pullanforderung im Stapel ausgeführt, sodass ihre vorhandene CI-Konfiguration nicht geändert werden muss.
• Stapelmetadaten sind in Workflowausdrücken verfügbar, github.event.pull_request.stackwenn Sie das Workflowverhalten speziell für gestapelte Pullanforderungen anpassen möchten. Da ein Workflow einmal pro Pull-Anforderung in einem Stapel ausgeführt wird, können Teams diese Metadaten verwenden, um teure Aufträge zu begrenzen und die CI-Nutzung zu reduzieren. Ausführliche Informationen findest du unter Optimieren von CI für gestapelte Pullanforderungen.

Eine optionale Ergänzung zu berücksichtigen: Wenn Entwickler Pullanforderungen nach dem Erstellen eines Stapels neu anordnen müssen, ohne ihn aufzulösen, übernehmen Sie die gh stack Erweiterung für GitHub CLI. Die direkte Neuanordnung erfordert gh stack modify; auf der GitHub Website müssen Entwickler die Pullanforderungen aufheben und den Stapel in der gewünschten Reihenfolge neu erstellen.

Ein Stapel wird auch automatisch geschlossen, sobald jede Pullanforderung darin zusammengeführt wurde. Wenn ein Team neue Verzweigungen über einem zusammengeführten Stapel hinzufügt und ausgeführt wird gh stack submit, startet die CLI einen neuen Stapel mit demselben Basiszweig. Das Original wird nicht erweitert. Teams, die über eine Reihe von Änderungen hinweg arbeiten möchten, sollten planen, den Stapel offen zu halten, bis alle Arbeiten abgeschlossen sind.

Eine vollständige Liste der Regeln und Anforderungen finden Sie unter Gestapelte Pullanforderungen.

3. Pilot mit einer kleinen Gruppe

Wählen Sie eine kleine Gruppe von Entwicklern aus, die ein hohes Codevolumen erstellen, entweder selbst oder über Copilot oder andere Codierungs-Agents. Bitten Sie die Gruppe, anstelle eines einwegbaren Beispiels eine echte repräsentative Funktion für das Pilotprojekt zu verwenden.

Um ihren ersten Stapel zu erstellen, leiten Sie Personen zu Schnellstart für gestapelte Pullanforderungen. Sammeln Sie nach dem Pilotprojekt Feedback von Entwicklern und Prüfern zu:

• Wie die Stapelplanung in ihren vorhandenen Workflow passt und ob Entwickler eine neu anordnende Neuanordnung benötigen, die die gh stack Erweiterung erfordert
• Ob sich der Prüfablauf jetzt anders anfühlt, als jede Pullanforderung im Stapel eigene erforderliche Überprüfungen und Statusprüfungen enthält
• Alle Support- oder Dokumentationslücken, die bei ihnen aufgetreten sind

4. Einführung und Unterstützung der Einführung

Teilen Sie nach dem Pilotprojekt die täglichen Anleitungen zum Erstellen, Überprüfen, Verwalten und Zusammenführen von Stapeln mit Teams: Gestapelte Pullanforderungen.

Wie in Schritt 2 erwähnt, empfehlen Sie die gh stackGitHub CLI Erweiterung, wenn Entwickler einen Stapel neu anordnen müssen, ohne ihn aufzulösen. Teams, die keine lokalen CLI-Tools verwenden, können den Stapel in der gewünschten Reihenfolge auf der GitHub Website aufteilen und neu erstellen.

Teams, die ein hohes Volumen von KI-generiertem Code produzieren, eines der passenden Signale aus Schritt 1, finden Anleitungen zum Stapeln von Änderungen von Codierungs-Agents in Stack AI-generierter Code in Pullanforderungen.

5. Aktualisieren Ihrer programmgesteuerten Tools

Um die Akzeptanz aufrechtzuerhalten, überprüfen Sie alle internen Tools, Bots oder Dashboards, die programmgesteuert Pullanforderungen erstellen, zusammenführen oder nachverfolgen, und aktualisieren Sie sie auf Stapel.

Wenn Ihre Organisation eine interne CLI oder andere Entwicklertools bereitstellt, können Sie die Stacks-API verwenden, um die Stapelerstellung und -verwaltung in diese vorhandenen Tools zu integrieren, anstatt Entwickler zu übernehmen gh stack.

Sie können auch stapelaktivität programmgesteuert nachverfolgen, z. B. über Dashboards, Bots oder interne Tools hinweg.

• REST-API: Jede von der API zurückgegebene Pullanforderung enthält ein stack Objekt, wenn sie zu einem Stapel gehört, wobei die Anzahl, Größe des Stapels, die Position der Pullanforderung darin und der Basiszweig des Stapels angezeigt wird. Eine dedizierte Stacks-API (GET /repos/{owner}/{repo}/stacks) listet auch jeden Stapel in einem Repository oder den spezifischen Stapel auf, der eine bestimmte Pullanforderung enthält. Siehe Gestapelte Pullanforderungen-APIs und Webhooks.
• Webhooks: Die pull_request Webhook-Nutzlast enthält dasselbe stack Objekt, wenn eine Pullanforderung zu einem Stapel gehört. Eine dedizierte stacked Aktion wird ausgelöst, wenn eine Pullanforderung zuerst einem Stapel hinzugefügt wird, sodass Sie den Moment eines Stapelformulars reagieren können.

In beiden Fällen ist stack das null Feld für eigenständige Pullanforderungen vorgesehen, sodass vorhandene Integrationen, die nicht erwarten, dass Stapel unverändert funktionieren.