LeoYeAI/openclaw-master-skills

Einrichtung

Bei der ersten Verwendung lies setup.md. Standard: Best-Practices-Modus (keine Konfiguration erforderlich).

Verwendung

Der Benutzer benötigt Git-Kompetenz – von grundlegenden Operationen bis zu komplexen Workflows. Der Agent übernimmt Branching, Merging, Rebasing, Konfliktlösung und Team-Kollaborationsmuster.

Architektur

Speicher in ~/git/. Siehe memory-template.md für die Struktur.

~/git/
└── memory.md    # Benutzereinstellungen (optional)

Kurzreferenz

Thema	Datei
Grundlegende Befehle	commands.md
Fortgeschrittene Operationen	advanced.md
Branch-Strategien	branching.md
Konfliktlösung	conflicts.md
History und Wiederherstellung	history.md
Team-Workflows	collaboration.md
Einrichtung	setup.md
Gedächtnis	memory-template.md

Kernregeln

1. Nie force push auf geteilte Branches – Verwende --force-with-lease nur auf Feature-Branches
2. Committe früh, committe oft – Kleine Commits lassen sich leichter überprüfen, rückgängig machen und mit bisect durchsuchen
3. Schreibe aussagekräftige Commit-Nachrichten – Erste Zeile unter 72 Zeichen, Imperativ
4. Pullen vor dem Pushen – Verwende immer git pull --rebase vor dem Pushen, um Merge-Commits zu vermeiden
5. Aufräumen vor dem Mergen – Nutze git rebase -i zum Squashen von Fixup-Commits

Team-Workflows

Feature-Branch-Flow:

1. git checkout -b feature/name ausgehend von main
2. Commits machen, regelmäßig pushen
3. PR öffnen, Review erhalten
4. Squashen und nach main mergen
5. Feature-Branch löschen

Hotfix-Flow:

1. git checkout -b hotfix/issue ausgehend von main
2. Fix, Test, Commit
3. Nach main UND develop mergen (falls vorhanden)
4. Release taggen

Täglicher Sync:

git fetch --all --prune
git rebase origin/main  # oder merge, falls das Team es bevorzugt

Commit-Nachrichten

• Verwende das konventionelle Commit-Format: type(scope): description
• Erste Zeile unter 72 Zeichen halten
• Typen: feat, fix, docs, style, refactor, test, chore

Push-Sicherheit

• Verwende git push --force-with-lease anstelle von --force – verhindert Überschreiben der Arbeit anderer
• Wird der Push abgelehnt, führe zuerst git pull --rebase aus, bevor du es erneut versuchst
• Niemals force push auf main/master-Branch

Konfliktlösung

• Nach dem Bearbeiten von Konfliktdateien prüfen, ob keine Markierungen mehr vorhanden sind: grep -r "<<<\|>>>\|===" .
• Testen, ob der Build funktioniert, bevor der Merge abgeschlossen wird
• Wird der Merge zu komplex, breche mit git merge --abort ab und versuche stattdessen git rebase

Branch-Hygiene

• Gemergte Branches lokal löschen: git branch -d branch-name
• Remote-Tracking bereinigen: git fetch --prune
• Vor dem Erstellen eines PRs den Feature-Branch auf den neuesten main rebasen
• Mit git rebase -i unordentliche Commits vor dem Pushen squashen

Sicherheits-Checkliste

Vor zerstörerischen Operationen (reset --hard, rebase, force push):

• Ist dies ein geteilter Branch? → History nicht umschreiben
• Habe ich uncommittete Änderungen? → Zuerst stashen oder committen
• Bin ich auf dem richtigen Branch? → git branch zur Überprüfung
• Ist das Remote auf dem neuesten Stand? → Zuerst git fetch

Häufige Fallstricke

• git user.email falsch – Überprüfen mit git config user.email vor wichtigen Commits
• Leere Verzeichnisse – Git verfolgt sie nicht, .gitkeep hinzufügen
• Submodule – Immer mit --recurse-submodules klonen
• Detached HEAD – Mit git switch - zum vorherigen Branch zurückkehren
• Push abgelehnt – Normalerweise ist zuerst git pull --rebase nötig
• stash pop bei Konflikt – Stash verschwindet. Stattdessen stash apply verwenden
• Große Dateien – Git LFS für Dateien >50 MB verwenden, niemals Secrets committen
• Groß-/Kleinschreibung – Mac/Windows ignorieren sie, Linux nicht – verursacht CI-Fehler

Wiederherstellungsbefehle

• Letzten Commit rückgängig machen, Änderungen behalten: git reset --soft HEAD~1
• Unstagede Änderungen verwerfen: git restore dateiname
• Verlorene Commits finden: git reflog (behält ~90 Tage History)
• Gelöschten Branch wiederherstellen: git checkout -b branch-name <sha-aus-reflog>
• Mit git add -p teilweise stagen, wenn ein Commit mehrere Änderungen mischt

Debuggen mit Bisect

Finde den Commit, der einen Fehler eingeführt hat:

git bisect start
git bisect bad                    # aktueller Commit ist fehlerhaft
git bisect good v1.0.0            # diese Version funktionierte
# Git checkt den mittleren Commit aus, teste ihn, dann:
git bisect good                   # oder git bisect bad
# Wiederholen, bis Git den Übeltäter findet
git bisect reset                  # zum ursprünglichen Branch zurückkehren

Kurzzusammenfassung

git status -sb                    # kurzer Status mit Branch
git log --oneline -5              # letzten 5 Commits
git shortlog -sn                  # Mitwirkende nach Commit-Anzahl
git diff --stat HEAD~5            # Änderungszusammenfassung der letzten 5 Commits
git branch -vv                    # Branches mit Tracking-Info
git stash list                    # ausstehende Stashes

Verwandte Skills

Installiere mit clawhub install <slug>, wenn der Benutzer zustimmt:

• gitlab – GitLab CI/CD und Merge Requests
• docker – Containerisierungs-Workflows
• code – Codequalität und Best Practices

Feedback

• Nützlich? clawhub star git
• Auf dem Laufenden bleiben: clawhub sync