gener8v/gener8v.claude-skills.engineering

Git-Branching

Jede Änderung kommt auf einen eigenen Branch. Das gilt auch für eine einzeilige Korrektur und eine Änderung ohne Issue. Committen Sie nicht auf dem Basis-Branch.

1. Basis-Branch finden

Verwenden Sie die erste Quelle, die eine Antwort liefert:

1. Repository-Anweisungen. Lesen Sie CLAUDE.md, CONTRIBUTING.md und Dokumente in .github/. Wenn dort ein Basis- oder Integrations-Branch genannt wird, verwenden Sie diesen.
2. Remote-Default-Branch.

   git symbolic-ref --short refs/remotes/origin/HEAD   # gibt origin/<name> aus
   gh repo view --json defaultBranchRef -q .defaultBranchRef.name
   

3. Mehrdeutigkeit. Wenn der Remote auch develop oder development hat und kein Dokument angibt, welcher der Basis-Branch ist, fragen Sie den Benutzer. Raten Sie nicht.

Wenn ein Integrations-Branch (z.B. develop) der Basis-Branch ist, startet ein Hotfix für eine veröffentlichte Version stattdessen vom Default-Branch. Verwenden Sie dies nur, wenn der Benutzer die Arbeit als Hotfix bezeichnet.

2. Prüfen, wo Sie sich befinden

git status --porcelain
git rev-parse --abbrev-ref HEAD

• Wenn der Working Tree Änderungen enthält, die Sie nicht vorgenommen haben, stoppen Sie. Fragen Sie den Benutzer, was damit geschehen soll.
• Wenn Sie sich bereits auf einem Branch für genau diese Arbeit befinden, bleiben Sie darauf.
• Wenn Sie auf dem Basis-Branch mit eigenen uncommitteten Änderungen sind, verschieben Sie diese: git switch -c <name> behält sie im Working Tree.

3. Branch vom Remote-Tip starten

git fetch origin --prune
git switch -c <name> origin/<base>
git log -1 --oneline

Durch den Start von origin/<base> aus schadet ein veralteter lokaler Basis-Branch nicht. Führen Sie nicht zuerst git pull auf dem Basis-Branch durch, um „aufzuholen“. Das ist nicht nötig.

4. Branch benennen

Verwenden Sie die Repository-Konvention, falls vorhanden. Ansonsten verwenden Sie <Typ>/<Ref>-<Slug>:

Teil	Werte
Typ	feat, fix, docs, chore, refactor, test, release, hotfix
Ref	Issue-Nummer (42), Pipeline-Ticket (ticket-007) oder nichts
Slug	Zwei bis fünf klein geschriebene Wörter, mit Bindestrichen verbunden

Beispiele: fix/42-null-session-crash, feat/ticket-007-search-filters, docs/readme-install-steps.

5. Während der Arbeit

• Committen Sie in kleinen Schritten, die jeweils für sich sinnvoll sind. Schreiben Sie den Betreff im Imperativ, maximal 72 Zeichen. Verwenden Sie den Textkörper, um das Warum zu erklären.
• Fügen Sie keinem Commit eine Co-Authored-By: Claude-Zeile hinzu. Das ist eine gener8v-Regel.
• Vor dem ersten Push können Sie auf origin/<base> rebasen. Nachdem der Branch gepusht wurde, mergen Sie stattdessen den Basis-Branch in den Branch. Ein Rebase eines gepushten Branches schreibt History um, und engineering:git-safety sichert dies ab.
• Pushen Sie mit einer Kette, die beim ersten Fehler abbricht:

  set -o pipefail
  git fetch origin && <test command> 2>&1 | tail -n 40 && git push -u origin HEAD
  

  Ohne set -o pipefail versteckt | tail den Exit-Code des vorherigen Befehls. Leiten Sie einen Git-Befehl oder einen Testbefehl niemals ohne set -o pipefail durch tail.

Parallele Arbeit

Für zwei oder mehr Agenten, die gleichzeitig Code editieren, lesen Sie resources/parallel-work.md, bevor Sie einen Agenten starten. Kurz gesagt: Ein Batch-Branch vom Basis-Branch, ein Worktree und ein Branch pro Agent vom Batch-Branch, und keine zwei Agenten auf denselben Dateien.

Fertig, wenn

• Sie sich auf einem Branch mit einem klaren Namen befinden, der beim aktuellen origin/<base> startet.
• git status keine Änderungen zeigt, die zu jemand anderem gehören.

Verwandte Skills

• engineering:github-pr-merge: PR öffnen, wenn die Arbeit abgeschlossen ist.
• engineering:git-safety: Genehmigungsregeln für Force-Push, Branch-Löschung und ähnliche Befehle.
• engineering:github-issue-workflow: Der gesamte Lebenszyklus eines Issues oder eines Pipeline-Tickets. Es ruft zuerst dieses Skill auf.