Ein großes mehrsprachiges Datenplattform-Monorepo ändern und Pull Requests vorbereiten

## Vor der ersten Änderung die Git-Remotes prüfen und den richtigen Zweig wählen Vor der ersten Bearbeitung oder Prüfung einer Sitzung: 1. Ermittle den persönlichen Fork und die maßgeblichen Upstream-Remotes. Wenn ihre Rollen unklar sind, bitte darum, die übliche Remote-Anordnung einzurichten. 2. Prüfe den Zeitstempel des Upstream-Standardzweigs und aktualisiere ihn, wenn die lokale Referenz veraltet ist. 3. Prüfe den Arbeitsbaum und bitte den Benutzer, nicht festgeschriebene Änderungen zu sichern, bevor du den Kontext wechselst. 4. Wähle den Zweig passend zur Aufgabe. Ermittle bei einer bestehenden Überprüfung deren Quellzweig, verwende einen passenden lokalen Zweig, falls einer vorhanden ist, und melde den Wechsel. Gibt es keinen passenden Zweig, frage, ob er abgerufen oder ein lokaler Zweig mit anderem Namen verwendet werden soll. Biete für neue Bearbeitungen als empfohlene Möglichkeit einen isolierten Arbeitsbaum auf Grundlage des Upstream-Standardzweigs oder einen neuen Zweig auf derselben Grundlage an. Verwende für reine Prüfarbeiten den Upstream-Standardzweig. ## Referenzausgaben von Tests und Protokolldateien neu erzeugen statt sie von Hand zu bearbeiten Referenzausgaben von Tests gehören zu dem Testgerüst, das sie erzeugt. Lies vor ihrer Ausführung oder Aktualisierung die Dokumentation der Testsammlung, bearbeite erzeugte Erwartungsdateien niemals direkt und erzeuge sie über den unterstützten Arbeitsablauf neu. Prüfe den entstandenen Unterschied sorgfältig, bevor du ihn akzeptierst. Protokolldefinitionen gehören zu ihrer Schemaquelle. Lies die zusammen mit diesen Definitionen gespeicherte Dokumentation, bevor du Nachrichten oder Felder änderst, und nimm erzeugte Protokollartefakte von manuellen Bearbeitungen aus. ## Vor CI den Code in ASCII und innerhalb der Zeilenlänge halten Halte Bezeichner, Code und Kommentare in ASCII, sofern der Inhalt eines Zeichenkettenliterals oder Testaufbaus nicht wirklich andere Zeichen erfordert. Prüfe geänderte Dateien stichprobenartig auf typografische Gedankenstriche, geschwungene Anführungszeichen, Auslassungspunkte und geschützte Leerzeichen, die häufig unbemerkt in Kommentare gelangen. Halte Quelltextzeilen innerhalb der Repository-Grenze, die üblicherweise bei 100 Zeichen liegt. Eine schnelle Prüfung hinzugefügter und geänderter Quelldateien kann Ausnahmen für Importe, package-Deklarationen und URLs näherungsweise berücksichtigen, liefert aber nur einen Hinweis. Maßgeblich bleiben die sprachspezifischen Linter. ## Die kleinste JVM-Testbasis wählen, die für den Test reicht Wähle die kleinste Testbasis, die das erforderliche Verhalten bereitstellt. Einfache Laufzeit- oder Hilfsprogrammtests sollten die Kernsuite nur mit allgemeinen Hilfen für Zeitüberschreitungen, temporäre Dateien, Protokollierung und Fehler verwenden. Tests von logischen Plänen, Analysatoren, Optimierern oder Planern sollten eine Plantestbasis verwenden, ohne eine SQL-Sitzung zu starten. SQL- oder Tabellentests sollten die Abfragetestbasis verwenden und einen ausdrücklichen Sitzungsanbieter als Mixin einbinden. Wähle für gewöhnliche SQL-Tests eine prozessinterne Sitzung und nur dann einen Data-Warehouse-gestützten Anbieter, wenn das Verhalten eines Data Warehouse erforderlich ist. Trage nicht die Kosten eines umfangreicheren Testaufbaus, nur weil benachbarte Tests ihn verwenden. ## Die passende Python-Testbasis für lokale, entfernte und gemischte Tests wählen Einfache Python-Tests sollten die übliche Komponententestbasis verwenden. Tests auf Kontextebene können zur Isolation für jeden Test einen neuen Ausführungskontext erstellen oder zugunsten der Geschwindigkeit einen Kontext je Klasse wiederverwenden. SQL- und DataFrame-Tests sollten die gemeinsame klassische Sitzungsbasis verwenden, während Tests von DataFrame-Erweiterungen eine spaltenorientierte Ausführung und spezielle Zusicherungen ergänzen können. Tests des entfernten Protokolls erfordern eine eigene Entscheidung: Verwende einen simulierten Testaufbau nur für Pläne, wenn kein Server benötigt wird, eine wiederverwendete entfernte Sitzung für echtes entferntes Verhalten oder einen gemischten klassischen und entfernten Testaufbau für Gleichlaufprüfungen. Behandle SQL-Hilfsprogramme, Zusicherungen strukturierter Fehler und Gleichheitshilfen als Mixins oder eigenständige Hilfen und nicht als Testbasen, sofern sie nicht die erforderliche Laufzeitumgebung erzeugen. ## Nur das geänderte Modul bauen und testen und vor dem vollständigen Testlauf fragen Erstellungsläufe und Tests können aufwendig sein. Wenn der Benutzer Tests ausdrücklich angefordert hat, führe sie aus. Frage andernfalls vor einer langen Prüfung der vollständigen Testsammlung, ob weitere Bearbeitungen zu erwarten sind. Bevorzuge das schnellere Werkzeug des Repositorys für inkrementelle Erstellungen, kompiliere nur das betroffene Modul und seinen Testcode und führe während der schrittweisen Bearbeitung eine einzelne Testsammlung oder einen benannten Fall aus. Halte eine Shell für inkrementelle Erstellungen geöffnet, wenn dies wiederholte Modultests verkürzt. Erstelle für Python-Testsammlungen, die von einem kompilierten Backend abhängen, zuerst das erforderliche Funktionsprofil, aktiviere die vom Benutzer gewählte virtuelle Umgebung oder die dokumentierte Standardumgebung und lege diese Umgebung nur an, wenn sie fehlt. Verwende die Auswahlmöglichkeiten des projektbezogenen Testausführers für Testsammlungen und Fälle. ## Vor dem Beheben eines Fehlers alle fehlgeschlagenen CI-Prüfungen auflisten Liste jede fehlgeschlagene Prüfung des zur Überprüfung stehenden Commits auf, bevor du einen einzelnen Fehler untersuchst. Eine erfolgreiche oder fehlende Prüfung der Testzusammenfassung beweist nicht, dass CI vollständig erfolgreich ist. Linter, Lizenzen, Abhängigkeiten, Kompatibilitätsprüfungen, Kompilierung und Dokumentationserstellung können in getrennten Aufträgen ohne Testhinweise fehlschlagen. Nutze bei Testaufträgen die Fehlerhinweise, um Testsammlung, Fall und Meldung zu ermitteln. Ermittle bei anderen Aufträgen den fehlgeschlagenen Schritt und lies das auf diesen Auftrag begrenzte Protokoll. Lade keine sehr großen Protokolle aufgeteilter Tests herunter, wenn strukturierte Hinweise bereits die nützlichen Belege enthalten. ## Prüfen, ob ein als geschlossen angezeigter Pull Request doch zusammengeführt wurde Gehe nicht davon aus, dass eine als geschlossen gekennzeichnete Überprüfung abgelehnt wurde. Manche Projekte führen Änderungen mit eigenen Werkzeugen zusammen. Deshalb kann der Hostingdienst eine erfolgreich zusammengeführte Überprüfung als geschlossen und ohne systemeigenen Zeitstempel der Zusammenführung anzeigen. Nutze die Projekthilfe für den Zusammenführungsstatus, um festzustellen, ob die Änderung aufgenommen wurde und welche Haupt- oder Wartungszweige sie enthalten. Behandle offen, zusammengeführt und ohne Zusammenführung geschlossen als verschiedene Ergebnisse. Melde fehlende Authentifizierung, einen unvollständigen Verlauf durch einen flachen Abruf, unbekannte Überprüfungen oder fehlende Upstream-Remotes als Einschränkungen der Umgebung. ## Titel und Beschreibung des Pull Requests nach den Projektvorgaben schreiben Befolge die Titelkonvention des Projekts für Vorgangskennungen und Komponentenmarkierungen, einschließlich dokumentierter Ausnahmen für Entwürfe, laufende, geringfügige oder triviale Änderungen. Leite den Titel aus dem Unterschied ab. Fehlt ein erforderlicher Vorgang, erstelle ihn mit der Projekthilfe unter Angabe der genauen Komponente und entweder eines Vorgangstyps oder eines referenzierten übergeordneten Vorgangs. Zeige anschließend den erstellten Vorgang und seine Felder deutlich zur Überprüfung an. Lies die Vorlage für Änderungsanträge des Repositorys, bevor du die Beschreibung entwirfst, und fülle jeden Abschnitt aus. Verwende den vollständigen Komponentennamen anstelle der abgekürzten Titelmarkierung, wenn die Vorgangsverwaltung dies verlangt. ## Nur in den eigenen Fork pushen und vor jedem Schreiben nach außen um Erlaubnis fragen Führe `push` niemals gegen das maßgebliche Upstream-Repository aus, sondern nur gegen den Fork des Beitragenden. Führe für bereits im Remote vorhandene Commits weder `force-push` noch `amend` aus, sofern der Benutzer dies nicht ausdrücklich verlangt. Wenn der entfernte Zweig fortgeschritten ist, führe vor `push` zuerst `fetch` und `rebase` aus. Hole vor externen Schreibvorgängen eine ausdrückliche Genehmigung ein, etwa vor dem Übertragen von Commits, Erstellen eines Änderungsantrags oder Vorgangs sowie Veröffentlichen von Kommentaren. Verwende den vom Projekt unterstützten authentifizierten Client. Ist er nicht verfügbar, bereite eine Überprüfungsadresse oder genaue Übergabeanweisungen vor, statt den vorgeschriebenen Arbeitsablauf zu umgehen. ## Die Versionsnummer des Zweigs verwenden, der die Änderung zuerst veröffentlicht Wenn Code einen Versionshinweis, eine Konfigurationsversion oder einen Kompatibilitätsausschluss benötigt, verwende die Version des Zweigs, in dem die Änderung zuerst veröffentlicht wird, und entferne die snapshot-Endung. Verwende für eine Überprüfung auf Grundlage eines Wartungszweigs dessen Version. Verwende für eine Überprüfung auf Grundlage des Hauptzweigs die Version des neuesten Veröffentlichungszweigs, wenn Änderungen üblicherweise dorthin rückübertragen werden. Verwende die Version des Hauptzweigs nur für Arbeiten, die ausschließlich dort gelten, etwa eine grundlegende oder binär inkompatible Änderung oder eine Abhängigkeitsaktualisierung, die keine dringende Rückübertragung rechtfertigt. Ist der Veröffentlichungsweg unklar, frage nach, statt ihn allein aus dem Hauptzweig abzuleiten. ## Vor dem Melden eines Sicherheitsproblems die Sicherheitsrichtlinie des Projekts lesen Lies vor der Meldung eines Sicherheitsproblems die Sicherheitsrichtlinie und das Bedrohungsmodell des Repositorys. Prüfe den angegebenen Geltungsbereich, ausgeschlossene Fälle und dokumentierte Fälle, die nicht als Sicherheitsbefund gelten, damit das Ergebnis eines Prüfprogramms anhand der tatsächlichen Zusicherungen des Projekts bewertet wird. Trenne Sicherheitsuntersuchungen von der gewöhnlichen Fehlerbewertung, bewahre Belege auf und lege beim Dokumentieren eines Befunds weder Zugangsdaten noch vertrauliche lokale Daten offen.