machichdigital

IDE-Tools · Foto: Homedust, CC BY 2.0

RuleWindsurf Rules & Cross-IDE-RulesLizenz: MITfrei kopierbar

commit-push.md

Zuletzt aktualisiert:

⬇ Als Datei laden

⧉ –× kopiert⬇ –× heruntergeladenBewertung:

Typ

Rule

Lizenz

MIT

Anwendungsfeld

Windsurf Rules & Cross-IDE-Rules

Solo-Entwickler

Voraussetzungen

  • Konfiguriertes Remote origin
  • Arbeit auf einem Feature-Branch, nicht auf main oder master
  • Optional vorhandene Lint-, Test- oder Build-Skripte

Einordnung

AufwandEinrichtung & Einarbeitung2/5 · eher geringNutzenErtrag im Alltag3/5 · mittelVoraussetzungenWas vorher da sein muss2/5 · eher gering1 = gering5 = hoch

Der eingebaute Branch-Schutz senkt das Risiko, der eigentliche Zeitgewinn bleibt aber überschaubar.

Commit + Push in einem Schritt

Für wen: Solo-Entwickler

Im Detail

Erweitert den reinen Commit-Workflow um einen automatischen Push zum Remote-Branch, inklusive eingebauter Sperre gegen direkte Pushes auf main oder master. Optional lassen sich vor dem Push Qualitätschecks wie Lint, Tests oder Build einbinden. Der Mehrwert gegenüber manuellem Vorgehen liegt in der eingebauten Schutzschicht: Ein versehentlicher Push auf den Hauptbranch wird technisch verhindert statt nur per Konvention vermieden. Geeignet für Entwickler, die auf Feature-Branches zügig vom lokalen Stand zum remote sichtbaren Stand kommen wollen, ohne den PR-Schritt sofort mitzuerledigen.

Schritt für Schritt

  1. Vor der Ausführung prüfen, dass Sie tatsächlich auf einem Feature-Branch sind, auch wenn die Regel das zusätzlich absichert
  2. Falls vorhanden, die optionalen Lint-, Test- oder Build-Skripte in den Ablauf einhängen
  3. Die Commit-Message nach dem projektinternen Format formulieren, bevor der Push ausgelöst wird
  4. Nach dem Push im Remote kontrollieren, ob Branch und Commits wie erwartet angekommen sind
  5. Bei fehlgeschlagenem Push wegen Branch-Schutzregeln die Fehlermeldung lesen statt den Schutz zu umgehen

Beispiel aus der Praxis

Sie arbeiten auf einem Branch fix/debug-logs, committen mit MSG=“fix: Remove unnecessary debug log output”, und der Ablauf pusht direkt danach zu origin fix/debug-logs, sodass die Änderung für das Team sichtbar wird, ohne dass main berührt wird.

Praxis-Tipp

Setzen Sie es am Ende eines Arbeitsschritts auf einem Feature-Branch ein, etwa MSG=“feat: Login-Flow ergänzt” — bei main oder master bricht die Regel automatisch mit Fehlermeldung ab.

Stolperfallen

Ohne eingebundene Qualitätschecks landet ungetesteter Code sofort remote sichtbar auf dem Feature-Branch, da diese Checks laut Regel nur optional sind. Zudem entfällt der Schutz vor Pushes auf main oder master, falls die Branch-Prüfung im Skript manuell umgangen wird.

Siehe auch

Lizenz & Quelle

Häufige Fragen.

Kann ich damit versehentlich auf main pushen?

Nein, der Ablauf prüft den aktuellen Branch und bricht bei main oder master explizit mit einer Fehlermeldung ab.

Sind Tests und Linting Pflicht vor dem Push?

Nein, laut Ablauf sind Qualitätschecks optional und müssen bei Bedarf selbst ergänzt werden.

Erstellt das automatisch einen Pull Request?

Nein, dieser Workflow endet nach dem Push, die PR-Erstellung ist Teil des separaten commit-push-pr-Workflows.

Inhalt ansehen (commit-push.md)
Lade …

Erfahrungen & Kommentare.

Funktioniert der Rule bei Ihnen? Tipps, Stolperfallen, Varianten — teilen Sie es mit der Community.

Lade Kommentare …

Ihre IP-Adresse wird zum Schutz vor Missbrauch gespeichert und nach 14 Tagen automatisch entfernt (Datenschutz).

Passt dazu.

v5.md

Basis-Regelwerk: Task-Klassifizierung (leicht/standard/kritisch), Tool-Nutzung, Antwortstil

MIT♥ –⧉ –