Der professionelle Entwickler-Workflow

Wie jedes Tech-Unternehmen der Welt Code ausliefert

⏱ ca. ~13 Min

01 · Lesen

Du hast jede einzelne Fähigkeit gelernt: Terminal, Dateien, git, Webserver, APIs, Claude Code, Debuggen, Deployen. Jetzt kombinieren wir alles zu dem Workflow, dem jedes professionelle Entwicklungsteam folgt.

Die Werkzeuge variieren — manche Teams nutzen GitLab statt GitHub, manche deployen zu AWS statt Render, manche nutzen andere Sprachen. Aber der Workflow ist immer derselbe. Lernst du diesen Workflow, kannst du in jedes Tech-Unternehmen laufen und verstehen, wie sie Software ausliefern.

💡 Stell dir das so vorEinzelne Fähigkeiten zu lernen ist wie Dribbeln, Passen und Werfen zu üben. Der professionelle Workflow ist das echte Spiel — die koordinierte Abfolge, wie alles zusammenwirkt, um ein Ergebnis zu erzeugen. Den Workflow zu verstehen ist der Unterschied zwischen programmieren können und ausliefern können.

02 · Schritt für Schritt

Der komplette Entwicklungszyklus. Jedes Feature, jeder Bugfix, jede Verbesserung folgt genau dieser Schleife.

1. ISSUE

Jemand meldet einen Bug oder fordert ein Feature an. Das wird in GitHub Issues, einem Jira-Board oder einer einfachen To-do-Liste verfolgt. Jede Arbeit startet mit einem klar beschriebenen Problem oder Ziel.

2. BRANCH

Branch erstellen: git checkout -b fix-login-bug. Niemals direkt auf main arbeiten. Ein Branch isoliert deine Änderungen, du kannst experimentieren, ohne etwas kaputtzumachen.

3. CODE

Mit Claude Code den Fix oder das Feature implementieren. Klar beschreiben, was du willst, das Ergebnis prüfen und iterieren, bis es passt. Hier wird tatsächlich gebaut.

4. TEST

Lokal verifizieren, dass es funktioniert. Randfälle prüfen. Geht etwas anderes kaputt? Probier seltsame Eingaben, leere Felder, unerwartete Szenarien. Wenn es automatisierte Tests gibt, lass sie laufen.

5. REVIEW

git diff ausführen. Geh deine Änderungen Zeile für Zeile selbst durch. Würdest du das genehmigen, wenn jemand anderes es geschrieben hätte? Achte auf vergessene console.log, hartcodierte Werte oder Dinge, die nicht reingehören.

6. COMMIT

Stagen und committen mit einer beschreibenden Message. Eine logische Änderung pro Commit. 'Fix login validation to reject empty passwords' erzählt eine Geschichte. 'Fixed stuff' nicht.

7. PUSH

Deinen Branch zu GitHub pushen: git push -u origin fix-login-bug. So werden deine Änderungen für andere sichtbar und reviewbar.

8. PULL REQUEST

Auf GitHub einen PR erstellen. Beschreibe, was du geändert hast und warum. Hier prüfen Teammitglieder (oder das zukünftige Ich) den Code, bevor er live geht. Kontext mitgeben: Was war der Bug? Wie hast du ihn behoben? Wie sollen andere testen?

9. MERGE

Nach Review und Freigabe in main mergen. Der Feature-Branch hat seinen Zweck erfüllt und kann gelöscht werden. Deine Änderungen sind jetzt Teil der offiziellen Codebasis.

10. DEPLOY

Ist Auto-Deploy konfiguriert (wie bei Render), gehen deine Änderungen automatisch live, sobald sie in main gemergt sind. Sonst triggerst du das Deployment manuell. So oder so — der Zyklus ist abgeschlossen, von der Idee bis zum Live-Feature.

03 · Lesen

Lass uns die zentralen git-Schritte des Workflows hands-on durchgehen. Du hast ein Projekt, das noch nicht von git getrackt wird — initialisieren, Feature-Branch erstellen, Änderung machen, stagen.

04 · Terminal-Übung

Jedes Projekt startet mit git init. Damit wird aus einem normalen Ordner ein git-Repository, in dem du Änderungen verfolgen kannst.

(Diese Sektion ist interaktiv — aktiviere JavaScript, um sie zu nutzen.)

05 · Terminal-Übung

Schritt 1: BRANCH — einen neuen Feature-Branch erstellen. Niemals direkt auf main arbeiten. Branches lassen dich gefahrlos experimentieren.

(Diese Sektion ist interaktiv — aktiviere JavaScript, um sie zu nutzen.)

06 · Terminal-Übung

Schritt 2: CODE — eine Änderung am Projekt machen. Wir fügen ein Login-Formular zu einer HTML-Datei hinzu.

(Diese Sektion ist interaktiv — aktiviere JavaScript, um sie zu nutzen.)

07 · Terminal-Übung

Schritt 3: COMMIT — Datei stagen und mit beschreibender Message committen. Eine gute Commit-Message erklärt was sich geändert hat und warum.

(Diese Sektion ist interaktiv — aktiviere JavaScript, um sie zu nutzen.)

08 · Lesen

🎯 Halbzeit — BRANCH → CODE → COMMIT geschafft

Du hast gerade die ersten drei Schritte des Alltags eines professionellen Entwicklers durchlaufen: Branch öffnen → Code schreiben → mit beschreibender Message committen. Diesen Dreischritt geht jedes Team so, egal wie groß das Projekt ist.

In der zweiten Halbzeit folgen noch PR (Pull Request) → Code-Review → Merge — also wie du deinen Branch dem Team zur Übernahme in den Hauptzweig vorschlägst.

Warum nicht direkt in main mergen? Weil ohne Review Bugs reinrutschen, die niemand abfängt. Der PR ist die Stelle, an der Teammitglieder deine Änderungen sehen, Feedback geben und freigeben. Diese Schicht ist der Kern professioneller Softwareentwicklung.

Kernpunkte

Dreischritt: Branch / Code / Commit (erledigt)
Verbleibende Schritte: Push / Pull Request / Code-Review + Merge
Die Commit-Message erklärt was und warum — das zukünftige Ich dankt dem heutigen Ich

09 · Quiz

Was erstellst du im professionellen Workflow, bevor du anfängst, Code zu schreiben?

Ein neues Repo
Eine Datenbank
Einen neuen Branch
Ein GitHub-Issue, das die Arbeit beschreibt

10 · Ausfüllen

Nachdem du das Feature fertig hast, erstellst du einen Pull _____, um das Mergen deiner Änderungen vorzuschlagen.

11 · Lesen

Glückwunsch. Du bist gerade demselben Workflow gefolgt, den Google, Stripe, Shopify und jedes andere Tech-Unternehmen nutzen. Die Größenordnung ist anders, aber der Workflow ist derselbe: Issue, Branch, Code, Test, Review, Commit, Push, PR, Merge, Deploy.

Große Unternehmen durchlaufen diese Schleife hunderte Male pro Tag. Jetzt machst du das auch.

12 · Quiz

Du hast gerade einen Bugfix auf einem Feature-Branch geschrieben. Was solltest du vor dem Commit tun?

git diff ausführen und deine Änderungen Zeile für Zeile prüfen
Direkt nach main pushen
Einen Pull Request erstellen
Den Branch löschen und neu anfangen

13 · Ausfüllen

Im professionellen Workflow startet jede Arbeit mit einem klar beschriebenen _____ — einem Bugreport oder Feature-Request.

Andere Lektionen aus diesem Kapitel

⚠ Das volle interaktive Erlebnis braucht JavaScript. Bitte aktiviere es und lade die Seite neu.

※ Diese Seite ist ein unabhängiges Bildungsprojekt — kein offizielles Anthropic-Produkt. Claude™ ist eine eingetragene Marke von Anthropic, PBC.