Git-Workflow mit Claude Code: saubere Branches, kleine Commits, CI und Team-Übergabe

Je schneller Claude Code schreibt, desto klarer muss dein Git-Workflow sein. Die kritischen Fehler entstehen selten, weil die KI gar nichts kann. Sie entstehen, weil fremde Dateien im Diff landen, Commits zu groß werden, Konflikte ohne Fachkontext aufgelöst werden oder ein Push passiert, bevor lokale Checks gelaufen sind.

Dieser Leitfaden beschreibt einen Git-Workflow für Solo- und Teamarbeit mit Claude Code: sauberer Branch-Loop, kleine Commits, Review-Gate, Worktree-Hygiene, Konfliktbehandlung, sicherer Rollback, CI vor dem Push und eine tägliche Übergabe. Staging, Commit und Rebase werden bewusst einfach erklärt.

Passende Folgeartikel: Git-Konflikte mit Claude Code lösen, GitHub Actions Advanced und review workflow checklist. Offizielle Referenzen: Claude Code hooks, Claude Code headless mode, Git user manual, Git rebase, GitHub Actions workflow syntax und pre-commit.

Git-Begriffe ohne Umwege

Der working tree ist der Bereich, in dem Dateien gerade bearbeitet werden. Claude Code schreibt ebenfalls dort. Die staging area ist der Korb für den nächsten Commit. git add speichert nicht alles endgültig, sondern wählt aus, was in den nächsten Commit soll.

Ein Commit ist ein benannter Schnappschuss der gestagten Änderungen. Ein guter Commit ist klein genug, dass ein Reviewer ihn in einem Durchgang versteht. Rebase bedeutet, deine Branch-Commits auf den aktuellen Stand von main neu aufzulegen. Das macht die Historie lesbarer, ist aber gefährlich, wenn andere denselben Branch bereits nutzen.

Claude Code sollte nicht nur Code generieren. In einem belastbaren Workflow liest es den Diff, schlägt Staging vor, formuliert Commit-Messages, erklärt Konflikte, startet lokale Checks und schreibt eine Übergabe.

flowchart LR
  A["Ziel notieren"] --> B["main aktualisieren und Branch erstellen"]
  B --> C["Kleine Aenderung implementieren"]
  C --> D["Diff lesen und Staging waehlen"]
  D --> E["Review Gate und lokale CI"]
  E --> F["Kleiner Commit"]
  F --> G["Rebase oder PR"]
  G --> H["Handoff und Rollback"]

Sauberer Branch-Loop

Vor der ersten Änderung muss der Arbeitsstand verständlich sein. Sauber heißt nicht immer “keine Änderungen”, sondern “keine fremden Änderungen in dieser Aufgabe”.

git status --short
git fetch origin
git switch main
git pull --ff-only origin main
git switch -c feature/checkout-coupon-validation
git status --short

In PowerShell hilft ein Datum im Branchnamen, wenn mehrere Sessions parallel laufen.

$topic = "checkout-coupon-validation"
$date = Get-Date -Format "yyyyMMdd"
git fetch origin
git switch main
git pull --ff-only origin main
git switch -c "feature/$date-$topic"
git status --short

Der erste Prompt sollte den Scope festlegen.

Goal: add coupon expiry validation to checkout.
Scope: edit only src/checkout, src/coupons, and matching tests.
Do not stage, commit, push, or edit unrelated files.
Before editing, read package.json and existing checkout tests.
After editing, show git diff --stat and the exact test commands you ran.

Masa hat bei ClaudeCodeLab mehrfach gesehen, dass eine Artikelaufgabe nebenbei Produktentwürfe, lokale Reports oder Skripte berührte. Der Build war grün, aber der Diff war nicht mehr erklärbar. Darum gehört “nicht anfassen” genauso in den Prompt wie das eigentliche Ziel.

Bewusstes Staging und kleine Commits

git add -A ist bequem, aber für KI-gestützte Arbeit zu breit. Es kann temporäre Dateien, lokale Einstellungen und fremde Arbeit aufnehmen.

git diff --stat
git diff
git add src/checkout/validateCoupon.ts
git add tests/checkout/validateCoupon.test.ts
git diff --staged --stat
git diff --staged

Commit-Messages sollten suchbar und konkret sein.

git commit -m "feat(checkout): validate coupon expiry before payment"

Wenn Nutzer, Leser oder Umsatzpfade betroffen sind, füge einen Body hinzu.

git commit -m "fix(content): keep Claude Code Git workflow CTA localized" -m "Updates the localized article body, internal links, and review checklist so translated pages follow the same Git workflow."

Claude Code darf die Message vorschlagen, aber nicht selbst committen.

Read only the staged diff.
Propose one Conventional Commits message.
Do not run git commit.
Mention the user impact in the body if the change affects readers or customers.

Git-Regeln in CLAUDE.md

CLAUDE.md ist die Arbeitsanweisung für Claude Code im Repository. Sie ist kein Nutzer-README, sondern die Betriebsregel für den KI-Pair-Programmer.

# Claude Code Git rules

- Start every coding task with `git status --short` and report unrelated dirty files.
- Do not run `git add -A`, `git commit`, `git push`, `git reset --hard`, or `git clean -fd` unless the user explicitly asks.
- Keep commits small: one behavior change, one test update, or one content slug at a time.
- Before proposing a commit, show `git diff --stat` and `git diff --staged --stat`.
- If a conflict appears, explain both sides before editing the conflicted file.
- Run the closest local checks before push: lint, typecheck, test, build, or article metadata checks.
- Leave a handoff note with changed files, commands run, failing checks, and rollback option.

Im Team lohnt sich zusätzlich ein Hook. Claude Code Hooks sind benutzerdefinierte Befehle, die bei Tool-Events laufen.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(git *)",
            "command": "node .claude/hooks/block-dangerous-git.mjs"
          }
        ]
      }
    ]
  }
}

// .claude/hooks/block-dangerous-git.mjs
import process from "node:process";

let raw = "";
for await (const chunk of process.stdin) raw += chunk;

const input = JSON.parse(raw || "{}");
const command = input.tool_input?.command ?? "";

const blocked = [
  /git\s+reset\s+--hard\b/,
  /git\s+clean\s+-[^\s]*f/,
  /git\s+push\s+--force(?!-with-lease)/,
  /git\s+checkout\s+--\s+\./,
  /git\s+restore\s+\.\b/
];

if (blocked.some((pattern) => pattern.test(command))) {
  process.stderr.write(`Blocked risky Git command: ${command}\n`);
  process.exit(2);
}

Ein Hook ist ein Schutzgeländer, kein Ersatz für Review und CI.

CI lokal vor dem Push

Remote-CI ist zu spät für einfache Fehler. Ein lokaler Preflight führt nur vorhandene Skripte aus.

// scripts/claude-git-preflight.mjs
import { execSync } from "node:child_process";
import { existsSync, readFileSync } from "node:fs";

const run = (command) => {
  console.log(`\n$ ${command}`);
  execSync(command, { stdio: "inherit", shell: true });
};

run("git diff --check");
run("git diff --cached --check");
run("git status --short");

const pkg = existsSync("package.json")
  ? JSON.parse(readFileSync("package.json", "utf8"))
  : { scripts: {} };

for (const script of ["lint", "typecheck", "test", "build"]) {
  if (pkg.scripts?.[script]) run(`npm run ${script}`);
}

node scripts/claude-git-preflight.mjs

Prompt:

After implementation, run the local preflight.
If a command fails, stop and explain the first failing command, likely cause, and smallest next fix.
Do not push until the preflight is green.

pre-commit und GitHub Actions

pre-commit lässt Checks vor dem Commit laufen.

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: git-diff-check
        name: git diff whitespace check
        entry: git diff --check
        language: system
        pass_filenames: false
      - id: npm-test
        name: npm test when available
        entry: node scripts/claude-git-preflight.mjs
        language: system
        pass_filenames: false

python -m pip install pre-commit
pre-commit install
pre-commit run --all-files

Im PR prüft GitHub Actions dieselben Grundlagen.

# .github/workflows/claude-code-pr-gate.yml
name: Claude Code PR Gate

on:
  pull_request:
    branches: [main]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci
      - run: git diff --check origin/main...HEAD
      - run: npm run lint --if-present
      - run: npm run typecheck --if-present
      - run: npm test --if-present
      - run: npm run build --if-present

Konflikte, Rebase und Rollback

Ein Konflikt bedeutet, dass Git zwischen zwei Änderungen nicht automatisch wählen kann. Lass Claude Code zuerst beide Absichten erklären.

git fetch origin
git rebase origin/main
git status --short
git diff --name-only --diff-filter=U

We are in a rebase conflict.
For each conflicted file, explain what our branch changed and what origin/main changed.
Resolve only after explaining the business intent.
After editing, run the narrowest relevant test.
Do not continue the rebase until I approve the resolved diff.

git add src/checkout/validateCoupon.ts
npm test -- --runInBand validateCoupon
git rebase --continue

Wenn es falsch aussieht:

git rebase --abort

Für geteilte Commits ist git revert die sichere Rücknahme.

git log --oneline -5
git revert --no-edit HEAD
git status --short

Für uncommittete Dateien:

git restore --staged src/checkout/validateCoupon.ts
git restore src/checkout/validateCoupon.ts

Anwendungsfälle und Fehlerbilder

Solo-Feature: Branch feature/yyyyMMdd-topic, klare Dateien und Tests, ein Commit pro Verhalten, Preflight vor Push.

Team-PR: Die Implementierungssitzung committet nicht. Die Review-Sitzung liest nur den staged diff. Ein Mensch prüft PR-Titel, CI, Risiko und Rollback.

Inhalte und Produktseiten: Bei ClaudeCodeLab beeinflussen Artikel, Gumroad-Links, Training-CTAs und interne Links den Umsatz. Arbeite nach Slug und Locale, prüfe Description, Hero, CTA, Links und Lokalisierung.

Langfristiger Refactor: Tests zuerst, interne Änderung danach, Löschung zuletzt. Keine Komplettmigration in einem Commit.

Fehler	Ursache	Gegenmaßnahme
git add -A nimmt Fremdes mit	KI hat zu viele Dateien geändert	Nach Pfad stagen
Riesencommit	Zu viele Themen	Ein Ziel pro Commit
Konflikt falsch gelöst	Absicht nicht verstanden	ours/theirs erklären
Gefährlicher Push nach Rebase	Historie weicht remote ab	--force-with-lease nur nach Teamregel
Roter PR	Keine lokalen Checks	Preflight
Destruktiver Rollback	reset --hard	git revert für geteilte Commits

Tägliche Übergabe

Eine Übergabe ist kurz, prüfbar und wiederaufnehmbar.

## Handoff: 2026-06-02

Branch: feature/20260602-checkout-coupon-validation
Goal: validate coupon expiry before payment authorization

Changed:
- src/checkout/validateCoupon.ts
- tests/checkout/validateCoupon.test.ts

Checks:
- npm run lint: passed
- npm test -- --runInBand validateCoupon: passed
- npm run build: not run, no UI/build config touched

Risk:
- Coupon timezone boundary still needs one integration test.

Rollback:
- Revert commit `abc1234` if production checkout rejects valid coupons.

Nächster Schritt

Solo-Entwickler starten mit dem kostenlosen Claude Code Cheatsheet. Für wiederverwendbare Prompts, CLAUDE.md-Regeln und Review-Templates lohnt sich ein Blick auf die ClaudeCodeLab Produkte. Teams, die Branch-Regeln, CI, Berechtigungen, Rollback und Übergabe an einem echten Repository festziehen wollen, sollten Claude Code Training und Beratung nutzen.

Ergebnis aus der Praxis

Mit diesem Loop wurde die ClaudeCodeLab Review kleiner: nicht mehr alles neu lesen, sondern Slug, Locale, Metadaten, CTA und Diff-Scope prüfen. git diff --staged --stat und die Übergabe sind die wichtigsten Nachweise.