Claude Code mit GitHub nutzen: Commits, PRs und der Workflow

Wenn du als Entwickler oder Solopreneur ernsthaft mit der KI im Terminal arbeitest, kommst du am Thema Claude Code GitHub nicht vorbei. Denn der eigentliche Clou von Claude Code ist nicht nur, dass es Code schreibt, sondern dass es direkt in deinem Repository lebt – also in dem Projektordner, in dem dein Code liegt (Entwickler sagen kurz „Repo“): Es kann Git-Befehle ausführen, saubere Commits anlegen, Branches erstellen und über die gh CLI sogar Pull Requests und Issues auf GitHub verwalten. Und inzwischen geht es noch einen Schritt weiter: Mit der offiziellen GitHub App reicht ein @claude im Issue-Kommentar, und die KI legt selbstständig los. In diesem Artikel zeige ich dir praxisnah, wie du Claude Code mit GitHub kombinierst und so deinen kompletten Workflow vom ersten Commit bis zum gemergten Pull Request beschleunigst. Falls Claude Code bei dir noch gar nicht läuft: In der Claude Code Anleitung richtest du es in ein paar Minuten ein.

Warum Claude Code + GitHub?

Die Kombination aus Claude Code GitHub spart dir vor allem eines: Kontextwechsel. Normalerweise springst du zwischen Editor, Terminal und Browser hin und her. Claude Code bündelt das. Es arbeitet direkt in deinem Projektordner, sieht deine Dateien, kennt deinen Git-Status und kann auf Wunsch die nächsten Schritte selbst ausführen.

Und das läuft erstaunlich unspektakulär ab. Du sagst „Was habe ich eigentlich geändert?“, und Claude führt im Hintergrund git status, git diff und git log aus und packt die Ausgabe in seinen eigenen Kontext. Du musst dir also keine Befehle merken – du redest einfach normal.

Konkret heißt das:

• Claude Code liest deinen git diff und schreibt daraus aussagekräftige Commit-Messages.
• Es legt Feature-Branches an, statt dass du dir Namen ausdenken musst.
• Über die gh CLI erstellt es Pull Requests inklusive Beschreibung und kann Issues anlegen oder kommentieren.
• Es hilft beim Code-Review, indem es Änderungen erklärt und Schwachstellen findet.
• Es löst auf Zuruf sogar Merge-Konflikte – das Ding, vor dem sich alle drücken.

Du behältst dabei die Kontrolle: Claude Code fragt bei schreibenden oder potenziell riskanten Aktionen nach, bevor es etwas ausführt. Der Auto-Modus blockt inzwischen von sich aus destruktive Git-Befehle und Klassiker wie rm -rf. Du bist also nie außen vor, sondern gibst nur die langweiligen, repetitiven Schritte ab.

Git-Grundlagen mit Claude: Commits mit aussagekräftigen Messages

Der häufigste Anwendungsfall im Alltag sind Commits. Du hast etwas geändert, willst es sichern, aber keine Lust auf eine nichtssagende Message wie „update“ oder „fix stuff“. Genau hier glänzt Claude Code: Es schaut sich an, was du tatsächlich geändert hast, und formuliert eine Message, die später jemand (oder du selbst in drei Monaten) auch versteht.

Ein typischer Ablauf im Terminal sieht so aus. Du bittest Claude darum, deine Änderungen zu committen, und es führt im Hintergrund die passenden Git-Befehle aus:

$ claude

> Committe meine aktuellen Änderungen mit einer sinnvollen Message.

# Claude Code führt aus:
$ git status
$ git diff
$ git add src/auth/login.ts
$ git commit -m "feat(auth): Rate-Limiting für Login-Endpoint hinzufügen

- Begrenzt fehlgeschlagene Logins auf 5 Versuche pro Minute
- Verhindert Brute-Force-Angriffe auf die Auth-Route"

Noch kürzer geht es mit claude commit. Der Befehl analysiert deine gestagten Änderungen, generiert die Message und fragt dich vorher um Bestätigung. Ein Enter, fertig.

Conventional Commits: die Konvention, die Claude liebt

Damit die Messages nicht nur schön, sondern auch maschinenlesbar sind, hat sich ein Standard durchgesetzt: Conventional Commits. Der Aufbau ist simpel: <type>(<scope>): <description>, optional gefolgt von Body und Footer.

Die wichtigsten Typen im Überblick:

• feat – neues Feature (erhöht die Minor-Version)
• fix – Bugfix (erhöht die Patch-Version)
• docs, style, refactor, test, chore – alles, was drumherum passiert
• BREAKING CHANGE im Footer – erhöht die Major-Version

Das Schöne: Claude zieht sich sogar Issue-Nummern aus deinem Branch-Namen. Heißt dein Branch feature/USER-123-add-login, landet automatisch ein Closes #123 im Footer. Dein Issue schließt sich beim Merge also von selbst.

Dein eigener /commit-Slash-Command

Wenn du das jeden Tag machst, lohnt sich ein eigener Slash-Command. Du legst einfach eine Markdown-Datei unter .claude/commands/commit.md an, und ab sofort tippst du nur noch /commit:

---
allowed-tools: Bash(git add:*), Bash(git commit:*), Bash(git status:*)
model: haiku
description: Erstellt einen Conventional Commit aus den gestagten Änderungen
---

Aktueller Diff:
!`git diff --cached`

Erstelle daraus einen Commit im Conventional-Commits-Format.
Subject-Zeile: maximal 50 Zeichen, Imperativ, kein Punkt am Ende.
Body: Was und Warum, nicht Wie.

Zwei Details lohnen den zweiten Blick. Das ! vor dem Befehl führt ihn aus und injiziert die Ausgabe direkt in den Prompt – Claude sieht den Diff also, ohne extra nachzufragen. Und model: haiku sorgt dafür, dass das Ganze blitzschnell läuft. Für eine Commit-Message Opus 5 anzuwerfen wäre wie mit Kanonen auf Spatzen zu schießen.

Willst du auf Nummer sicher gehen, hängst du noch einen Pre-commit-Hook unter .git/hooks/commit-msg dran, der das Format per Regex prüft. Dann kommt gar nichts Unsauberes mehr durch – egal ob von dir oder von der KI.

Branches und Pull Requests mit der gh CLI erstellen

Hier wird die GitHub-Integration richtig stark. Claude Code nutzt die offizielle gh CLI von GitHub, um direkt aus dem Terminal mit deinem Remote-Repository zu sprechen. Voraussetzung: Du hast die gh CLI installiert und einmalig per gh auth login authentifiziert. Mit gh auth status prüfst du, ob alles sitzt. Danach kann Claude darüber Pull Requests, Issues und mehr verwalten.

Ein sauberer Workflow trennt deine Arbeit immer in einen eigenen Branch. Du kannst Claude Code einfach bitten, das Ganze zu übernehmen, von der neuen Branch bis zum fertigen Pull Request:

> Erstelle einen Branch für das neue Feature, committe und öffne einen Pull Request.

# Claude Code führt aus:
$ git checkout -b feature/rate-limiting
$ git add .
$ git commit -m "feat(auth): Rate-Limiting für Login-Endpoint"
$ git push -u origin feature/rate-limiting
$ gh pr create --title "Rate-Limiting für Login" \
    --body "Begrenzt Login-Versuche, um Brute-Force zu verhindern.

## Was geändert?
- Neue Middleware für Rate-Limiting
- Tests für den Login-Endpoint

## Warum?
- Schutz vor Brute-Force auf der Auth-Route

## Wie testen?
- npm run test -- auth"
$ gh pr checks --watch

Das Schöne daran: Claude formuliert die PR-Beschreibung aus den tatsächlichen Commits und Änderungen. Du bekommst also einen Pull Request, der reviewbar ist, statt einer leeren Beschreibung. Wenn dein Team Vorlagen nutzt, respektiert gh pr create auch deine PULL_REQUEST_TEMPLATE.md.

Der letzte Befehl ist übrigens der wichtigste: gh pr checks --watch wartet, bis deine CI durchgelaufen ist. Erst danach solltest du mergen. Klingt banal, wird aber ständig übersprungen.

Die gh-Befehle, die du wirklich brauchst

• gh pr create --draft und später gh pr ready – für alles, was noch nicht fertig ist
• gh pr list, gh pr view, gh pr diff – der Überblick
• gh pr merge --squash --delete-branch – sauber mergen und aufräumen
• gh issue create, gh issue list --label bug --state open, gh issue close
• gh workflow run und gh run watch – Actions aus dem Terminal steuern

Tipp: Lass Claude vor dem Push immer kurz den Plan zusammenfassen, gerade wenn du auf einem geteilten Repo arbeitest. So vermeidest du, versehentlich auf main zu committen.

Code-Review und Issues mit Claude

Claude Code ist nicht nur fürs Schreiben gut, sondern auch fürs Lesen. Du kannst es bitten, einen offenen Pull Request zu reviewen. Es zieht sich die Änderungen über die gh CLI, analysiert den Diff und gibt dir eine strukturierte Rückmeldung: potenzielle Bugs, fehlende Tests, unklare Benennungen oder Sicherheitsprobleme.

Dafür gibt es inzwischen zwei eingebaute Befehle. /code-review nimmt sich deinen aktuellen Branch vor und sucht gezielt nach Korrektheitsfehlern – nicht nach Stil-Nörgeleien, sondern nach Dingen, die wirklich kaputtgehen. Und /ultrareview schickt gleich ein ganzes Team von Agenten in der Cloud los. Mit /ultrareview 42 lässt du dir einen bestimmten Pull Request vorknöpfen.

Für die CI-Pipeline gibt es die Variante claude ultrareview --json. Damit kannst du das Ergebnis maschinell weiterverarbeiten, etwa als Kommentar am PR.

Ein paar typische Aufgaben, die du Claude im GitHub-Kontext geben kannst:

• PR reviewen: „Schau dir PR #42 an und sag mir, ob es Probleme gibt.“ Claude nutzt dann gh pr view und gh pr diff.
• Issue anlegen: „Erstelle ein Issue für den Bug, dass die Session nach dem Logout bestehen bleibt.“ Claude formuliert Titel und Beschreibung und legt es per gh issue create an.
• Issue abarbeiten: „Lies Issue #17 und implementiere die Lösung.“ Claude liest das Issue, schreibt den Code und kann am Ende den passenden Pull Request öffnen.
• Aufräumen: „Zeige mir alle offenen Bugs“ oder „Schließe Issue #15 mit einem Kommentar, dass es in PR #42 gefixt wurde.“

Damit wird dein Repository zum gemeinsamen Arbeitsbereich zwischen dir und der KI. Du beschreibst das Ziel, Claude erledigt die Umsetzung und dokumentiert sie nachvollziehbar in GitHub.

Bonus: Der GitHub-MCP-Server

Wenn dir die gh CLI nicht genug ist, gibt es eine tiefere Integrationsstufe: den offiziellen GitHub-MCP-Server. MCP steht für Model Context Protocol, eine standardisierte Schnittstelle, über die Claude Code mit externen Tools und Diensten spricht. Der GitHub-MCP-Server gibt Claude strukturierten Zugriff auf die GitHub-API, also auf Repositories, Pull Requests, Issues, Workflows und mehr, ohne dass jeder Befehl über die Kommandozeile laufen muss.

Remote oder lokal? Die Entscheidung in 30 Sekunden

Es gibt zwei Wege. Die Remote-Variante ist mein Favorit für den Alltag: kein Docker, kein Setup-Zirkus, eine Zeile im Terminal.

$ claude mcp add-json github '{
  "type": "http",
  "url": "https://api.githubcopilot.com/mcp",
  "headers": { "Authorization": "Bearer DEIN_PAT" }
}' --scope project

Dein Personal Access Token gehört dabei in eine .env-Datei – und die gehört in die .gitignore. Immer. Ohne Ausnahme.

Die lokale Variante läuft per Docker oder als Binary und ist die Wahl, wenn du GitHub Enterprise nutzt oder offline arbeiten musst:

$ claude mcp add github \
    -e GITHUB_PERSONAL_ACCESS_TOKEN=dein_token \
    -- docker run -i --rm \
    -e GITHUB_PERSONAL_ACCESS_TOKEN \
    ghcr.io/github/github-mcp-server

Kurz gegenübergestellt: Remote heißt kein Docker und wenig Aufwand, aber kein Enterprise und kein Offline-Betrieb. Lokal heißt Docker-Pflicht, dafür Enterprise und Offline. Mehr Entscheidungshilfe brauchst du ehrlich gesagt nicht.

Toolsets: weniger ist mehr

Der Server bringt über 18 Toolsets mit, aktiv sind standardmäßig nur fünf: context, repos, issues, pull_requests und users. Alles andere – actions, code_security, discussions, projects, dependabot und Co. – schaltest du gezielt dazu:

$ GITHUB_TOOLSETS="repos,issues,pull_requests,actions"

Warum nicht einfach alles aktivieren? Weil jedes Toolset Kontext-Token frisst, die dann für deinen eigentlichen Code fehlen. GitHub hat allein das Projects-Toolset zuletzt um rund 23.000 Token abgespeckt – das ist die Hälfte. Das zeigt ganz gut, welche Größenordnungen da im Spiel sind. Nutzt du einen klassischen PAT (die mit ghp_ am Anfang), filtert der Server die Tools inzwischen automatisch nach deinen Token-Berechtigungen.

Für die meisten Solopreneure reicht die gh CLI im Alltag trotzdem völlig aus. Der MCP-Server lohnt sich, wenn du komplexere Automatisierungen baust oder Claude Code stärker in deine GitHub-Prozesse einbetten willst. Du kannst problemlos mit der CLI starten und später umsteigen. Ein- und ausloggen geht dann per claude mcp login github beziehungsweise claude mcp logout github.

@claude in GitHub Actions: dein Bot im Repo

Jetzt kommt der Teil, der wirklich alles verändert. Mit der offiziellen GitHub Action lebt Claude nicht mehr nur in deinem Terminal, sondern direkt in deinem Repository. Die Action ist seit August 2025 offiziell verfügbar und läuft ganz normal auf GitHub-Runnern.

Der schnellste Weg rein: Du tippst in Claude Code einfach /install-github-app. Das installiert die App, legt das Secret an und schreibt dir Beispiel-Workflows ins Repo. Du brauchst dafür Admin-Rechte am Repository.

Es gibt zwei Modi. Im Interactive-Modus schreibt jemand @claude in einen Issue- oder PR-Kommentar, Claude erledigt die Aufgabe, committet auf einen Branch und antwortet. Im Automation-Modus gibst du im Workflow ein festes prompt an – dann läuft Claude ohne Mention los, etwa bei jedem neuen Pull Request.

Wichtig zu wissen: Claude öffnet Pull Requests nicht selbst. Es committet auf einen Branch und gibt dir einen Link zum PR-Erstellen. Der letzte Klick bleibt bei dir. Finde ich ehrlich gesagt gut so.

Workflow 1: Der @claude-Mention

name: Claude Mention
on:
  issue_comment:
    types: [created]

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
      issues: write
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          claude_args: "--max-turns 10"

Kein prompt-Feld – das ist der ganze Trick. Ohne Prompt weiß die Action, dass sie auf Mentions hören soll.

Workflow 2: Automatisches Review bei jedem PR

name: Claude Auto-Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "Reviewe den Diff dieses PRs auf Bugs, Security-Probleme und Performance. Sei konkret."
          claude_args: "--max-turns 5 --model claude-sonnet-5"

Das fetch-depth: 0 ist Pflicht, sonst sieht Claude die Historie nicht und kann den Diff nicht sauber bilden. Ein Klassiker unter den Fehlerquellen.

Authentifizierung: welcher Weg ist deiner?

• ANTHROPIC_API_KEY – der Standard, dein sk-ant--Key als Repo-Secret
• CLAUDE_CODE_OAUTH_TOKEN – wenn du Pro oder Max hast, einmal claude setup-token laufen lassen
• Workload Identity Federation per OIDC – für alle, die keine Keys herumliegen haben wollen
• Custom GitHub App Token per actions/create-github-app-token@v2 – nötig, wenn Claudes Commits weitere Workflows auslösen sollen

Der letzte Punkt ist der Fallstrick, über den alle stolpern: Commits, die mit dem Standard-GITHUB_TOKEN erstellt wurden, triggern keine nachgelagerten CI-Workflows. GitHub verhindert damit Endlosschleifen. Wenn deine Tests nach Claudes Commit einfach nicht anspringen, ist das fast immer die Ursache. Lösung: Claude GitHub App oder ein Custom App Token.

Noch ein Hinweis, falls du von alten Workflows migrierst: Aus direct_prompt wurde prompt, max_turns, model und allowed_tools wandern alle in claude_args, und mode ist ganz weggefallen – das erkennt die Action jetzt selbst.

Sicherheit und Best Practices

So praktisch die Automatisierung ist, ein paar Grundregeln solltest du beherzigen, damit dir die GitHub-Integration nicht um die Ohren fliegt.

Richtig machst du es so: Entweder du checkst den Base-Branch aus (also ohne ref:), oder du legst den Fork-Code in ein Unterverzeichnis und gibst nur dieses frei:

- uses: actions/checkout@v4
  with:
    ref: ${{ github.event.pull_request.head.sha }}
    path: pr-head        # Fork-Code isoliert im Unterordner

- uses: anthropics/claude-code-action@v1
  with:
    claude_args: "--add-dir pr-head"

Der Rest ist gesunder Menschenverstand, aber schreib ihn dir trotzdem hinter die Ohren:

• Arbeite immer in Branches. Lass Claude nie direkt auf main committen. Ein Feature-Branch plus Pull Request ist dein Sicherheitsnetz.
• Reviewe vor dem Merge. Auch wenn Claude den PR erstellt hat: Du entscheidest, was gemergt wird.
• Minimale Permissions. contents, pull-requests und issues auf write – mehr nicht. Kein admin, kein write:all.
• PAT-Scopes knapp halten. Für den MCP-Server reichen repo und optional read:org.
• Keine Secrets ins Repo. .env in die .gitignore, und chmod 600 ~/.claude/settings.json schadet auch nicht.
• Niemals allowed_non_write_users: '*' auf öffentlichen Repos. Und show_full_output auf public: auf keinen Fall.
• Modellwahl nach Aufgabe. Für anspruchsvolle Refactorings Opus 5, für den schnellen Alltag Sonnet, für leichte Tasks Haiku 4.5.

Gegen Prompt-Injection bereinigt die Action HTML-Kommentare, unsichtbare Zeichen, Image-Alt-Texte und HTML-Entities aus Kommentaren. Trotzdem: Aktiviere in den Repo-Settings unter Actions die Option „Require approval for all external contributors“. Und lass CLAUDE_CODE_SUBPROCESS_ENV_SCRUB einfach an – das ist der Standard und hat seinen Grund.

Der beste Hebel bleibt aber deine CLAUDE.md. Schreib deine Git-Konventionen dort rein: Commit-Format, Branch-Namen, PR-Aufbau, „immer gh statt curl“. Die Datei wird bei jedem Start geladen. Einmal schreiben, für immer Ruhe.

Die häufigsten Fehler und wie du sie umgehst

Ich sammle solche Stolpersteine gerne, weil sie sich fast alle mit einer Zeile lösen lassen. Die Klassiker:

• CI läuft nach Claudes Commit nicht. Standard-GITHUB_TOKEN ist schuld – nimm die GitHub App oder einen Custom App Token.
• Claude nutzt curl statt gh. Eine Regel in die CLAUDE.md, erledigt.
• Merge ohne CI-Check. Erst gh pr checks --watch, dann gh pr merge --auto.
• Draft-PRs sind gar keine Drafts. Explizit gh pr create --draft sagen, später gh pr ready.
• Riesen-Commits. „Commit nach jeder Änderung“ zu Sessionbeginn – Problem gelöst.
• Kein Remote konfiguriert. Sag einfach „Erstelle ein GitHub-Repo dafür und pushe“ – gh erledigt das komplett.
• --dangerously-skip-permissions in Actions. Auf öffentlichen Repos: niemals. Nutze @v1.

Und wenn gar nichts geht: /doctor. Der Befehl checkt dein Setup durch und sagt dir, was klemmt. Spart dir eine halbe Stunde Suchen.

Was sich zuletzt getan hat

Claude Code entwickelt sich schnell weiter, deshalb hier die Highlights rund um Git und GitHub, die du kennen solltest:

• /code-review und claude ultrareview für CI-Pipelines
• --from-pr versteht jetzt auch GitLab-MRs, Bitbucket und GitHub Enterprise
• Claude setzt automatisch eine AI_AGENT-Variable für gh-Subprozesse (Traffic-Attribution)
• Der Auto-Modus blockt destruktive Git-Befehle
• Worktree-Support mit worktree.baseRef und automatischem Aufräumen nach Squash-Merges
• Background-Subagents und Dynamic Workflows für richtig große Umbauten

Zur Abrechnung noch ein Wort, weil oft gefragt: Der geplante „Agent SDK Credit Pool“ liegt aktuell auf Eis. Actions verbrauchen also dein normales Subscription-Limit. Dazu kommen immer API-Tokens und GitHub-Runner-Minuten – rechne das bei Auto-Reviews auf großen Repos mit ein.

Der komplette Workflow von Issue bis Merge

So sieht das Ganze bei mir im Alltag aus, wenn alle Slash-Commands stehen:

> /branch "user-profile-page"     # main → pull → feat/user-profile-page
... entwickeln ...
> /lint
> /vitest
> /commit                        # feat(profile): Profilseite hinzufügen
> /push
> /pr                            # PR öffnen + gh pr checks --watch

$ gh pr merge --squash --delete-branch
$ git checkout main && git pull

Klingt nach viel? Ist es nicht. Du tippst fünf Slash-Commands, den Rest macht Claude. Und parallel dazu laufen im Repo die @claude-Mentions, die dein Team in Issues und PRs abfeuert.

Fazit

Die Verbindung von Claude Code GitHub macht aus deinem Terminal einen echten Co-Piloten für den gesamten Entwicklungs-Workflow. Von aussagekräftigen Commits über saubere Branches bis zu fertigen Pull Requests, automatischen Reviews und einem @claude-Bot im Repo übernimmt Claude die repetitiven Schritte, während du die Richtung vorgibst.

Fang klein an: Lass Claude beim nächsten Mal einfach deine Änderungen committen und beobachte, wie viel besser die Commit-Messages werden. Dann baust du dir einen /commit-Slash-Command. Dann kommt die gh CLI dazu. Und irgendwann installierst du die GitHub App, und plötzlich reviewt deine KI jeden Pull Request, bevor du ihn überhaupt aufmachst. Von da aus baust du dir Schritt für Schritt deinen persönlichen GitHub-Workflow mit Claude Code auf.

FAQ zu Claude Code und GitHub