Committen und pushen

12. August 2026 · Dubai, VAE
25.2048° nördlicher Breite · 55.2708° östlicher Länge · Zeitzone UTC+4
15.208. Lebenstag · 1.474. Tag in Dubai

Vor langer Zeit, noch in einem anderen Leben, versuchte mir ein Backend-Entwickler im Yandex-Büro zu erklären, dass man manchmal irgendetwas von einem Branch in einen anderen cherry-picken müsse.

Ich hörte aufmerksam zu. Ich versuchte überhaupt immer, Programmierern aufmerksam zuzuhören, denn ihren Gesichtern sah man an: Es ging um etwas höchst Wichtiges. Irgendwo existierte ein Baum mit Branches, auf denen Commits geschahen. Manchmal musste man Branches mergen, manchmal durfte man nicht, dann musste man etwas cherry-picken. In besonders schweren Fällen entstand ein Konflikt.

Mir als Produktdesigner kam das wie uralte Kabbala vor. Ich verstand Oberflächen, Abläufe und Informationsarchitektur. Ich konnte stundenlang streiten, warum Nutzer hier statt dort klicken, warum ein Button acht Pixel weiter links stehen sollte und warum das Produktteam schon den dritten Monat etwas entwarf, das die Menschen gar nicht brauchten. Ich konnte ein ziemlich komplexes System zeichnen und sein Verhalten in hundert Zuständen erklären. Dann aber kam die Grenze. Dahinter lebten die Programmierer.

Ich übergab ihnen Figma, sie verschwanden in ihren Terminals, und eine andere Physik der Welt begann. Dort gab es Repositories, Container, Umgebungen, Endpunkte, Migrationen, Schlüssel und das rätselhafte Git. Ich blieb auf meiner Seite des Flusses. So war für mich das Weltgefüge: Der Designer entwirft, der Programmierer baut. Der Architekt zeichnet die Karte, jemand anderes geht danach wirklich durch den Wald.

Viele Jahre vergingen. Ich zog nach Dubai, wechselte mehrere Leben, Berufe, Wohnungen, Teams, Oberflächen und Vorstellungen von mir selbst. Eines Tages saß ich mit dem Laptop irgendwo zwischen Villenbesichtigung in Tilal Al Ghaf, Immobiliengespräch, Änderungen an meiner Website, Kindern, Hund, Umzug nach Palm Jumeirah und dem nächsten Versuch, ein CRM für meine Maklertätigkeit zu bauen — und sagte ganz ruhig zum Agenten: committe die Änderungen und pushe sie.

Ich sah diesen Satz an und begriff plötzlich, dass etwas weit Bedeutenderes geschehen war als das Erlernen eines weiteren Werkzeugs.

Ich hatte den Fluss überquert.

Am Anfang war die Datei

Dateien haben eine unangenehme Eigenschaft: Sie existieren nur jetzt. Alte Designer kennen diese Archäologie gut: final.fig, final-final.fig, final-v2.fig, final-v2-new.fig, final-v2-new-real.fig. Jede neue Datei sollte irgendwie die Erinnerung an die vorige bewahren. Mal lag sie im Namen, mal im Ordner Archive, mal im Kopf des Designers, mal verschwand sie ganz. Jahrelang versuchten wir, Zeit von Hand zu verwalten.

Git bot eine völlig andere Art, über Vergangenheit nachzudenken. Man braucht nicht jedes Mal eine neue vollständige Weltkopie, wenn die Welt sich ändert. Man kann die Änderung selbst speichern: Hier war es so, dann habe ich es anders gemacht, hier ist der Grund und der Moment, in dem das System ein anderes wurde. Dieser Moment heißt Commit.

Ich brauchte viele Jahre, um die Schönheit dieses Wortes zu spüren — nicht technisch, sondern fast metaphysisch. Ein Commit ist ein Versprechen an die Wirklichkeit. Du sagst: Das ist der Zustand der Welt, für den ich jetzt einstehe. Vorher konnten Änderungen wie Bauschutt um dich herumliegen: ein paar Dateien bearbeitet, eine gelöscht, eine neu, irgendwo Logik geändert, anderswo vom Agenten aus unerfindlichem Grund das halbe Projekt umgeschrieben, obwohl niemand darum bat. Alles ist noch unsicher, alles lässt sich verwerfen.

Dann machst du einen Commit, und das Chaos bekommt einen Namen.

Layout der Objektkarte korrigieren, Eigentümerzuordnung hinzufügen, Authentifizierungsablauf wiederherstellen, Agentenanweisungen aktualisieren, aufhören, die Produktion kaputtzumachen.

Der letzte ist besonders wichtig.

In diesem Moment geschieht etwas Erstaunliches: Die Vergangenheit verschwindet nicht mehr. Sie wird zu einem Weg.

Lange dachte ich, Erinnerung sitze im Kopf

Vielleicht beschäftigt mich deshalb heute das Gedächtnis neuronaler Netze so sehr. Wir sehen Erinnerung gewöhnlich als menschliche Eigenschaft. Ich erinnere mich an das erste Büro, Moskau, die Räume unserer Produktdiskussionen und jenen Backend-Entwickler mit seinem Cherry-Pick, obwohl ich damals ziemlich sicher kein Wort verstand. Ich erinnere mich an den 30. Juli 2022, als meine eigene Dubai-Zählung begann.

Heute ist Tag 1.474. Man könnte ihn auch so aufschreiben: Dubai / Commit 1474.

In dieser Zeit änderte sich fast alles: Adressen, Arbeit, meine Vorstellungen von Arbeit, Menschen um mich, Kindergrößen, die Zahl der Dinge im Haus und der neuronalen Netze im Laptop, sogar die Definition meiner selbst. Doch menschliches Gedächtnis ist unzuverlässig. Es schreibt die Geschichte ständig um. Jedes Erinnern bearbeitet die Vergangenheit ein wenig für unser heutiges Ich.

Git funktioniert anders. Es ist ziemlich nüchtern. Es sagt: Das war, das änderte sich, derjenige änderte es, dann geschah es und deshalb — falls du eine vernünftige Nachricht geschrieben hast. In gewisser Weise ist git log eine der ehrlichsten Autobiografien, die ich kenne. Keine nachträgliche literarische Bearbeitung und kein Wunsch, rückblickend klüger auszusehen.

Dienstag, 02:14 — Authentifizierung kaputtgemacht

Dienstag, 02:47 — Authentifizierung repariert

Dienstag, 03:06 — repariert, was ich beim Reparieren der Authentifizierung kaputtgemacht habe

So ungefähr sieht das wirkliche Leben aus.

Dann kamen die Agenten

Hier änderte sich endgültig alles. Früher war der Computer ein Werkzeug: Tasten drücken, Maus bewegen, Programm öffnen und eine Handlung direkt ausführen. Dann kam Software, die Befehle ausführen konnte. Heute öffne ich ein Projekt, und darin können Wesen arbeiten, denen ich nur die Absicht beschreiben muss.

Eine liest Code, eine andere untersucht die Architektur, die dritte korrigiert die Oberfläche, die vierte prüft das Ergebnis der ersten. Eine fünfte schreibt vielleicht eine Datenbankmigration, während ich ein Townhouse besichtigen fahre. Allmählich mache ich nicht mehr jede Bewegung von Hand, sondern gebe zunehmend die Bewegungsrichtung vor.

Früher entwarf ich die Schnittstelle zwischen Mensch und Programm. Jetzt entwerfe ich sie zwischen menschlicher Absicht und vielen künstlichen Ausführenden. Plötzlich brauche ausgerechnet ich die alten Programmiererwörter.

Arbeitet ein Mensch für dich, kannst du noch auf sein Gedächtnis hoffen. Bei Agenten endet diese Hoffnung schnell. Sie brauchen ein Gebiet, Regeln, Geschichte und das Verständnis, was sie hier anfassen dürfen und was nicht. Sie brauchen Kontext als Dateien, nicht als meine Intuition.

So kam in mein Leben .gitignore, und völlig unerwartet entdeckte ich darin eines der philosophischsten Dinge der gesamten Entwicklung.

.gitignore ist eine Liste dessen, was die Welt vergessen soll.

Nicht alles verdient Geschichte. Es gibt temporäre Dateien, Geheimnisse, Müll, Zwischenartefakte und Dinge, die nur auf deinem Rechner existieren und nicht weitergeschickt werden müssen. Um Erinnerung richtig zu bewahren, muss man zuerst entscheiden, was man nicht behalten soll. Die Menschheit kam darauf offenbar deutlich später als Git.

Und dann gibt es AGENTS.md und andere Dateien, in denen du Anweisungen für Nachkommende hinterlässt. Heute müssen das keine Menschen sein. Du schreibst buchstäblich einen Brief an Wesen aus der Zukunft: Hier ist das Projekt, so funktioniert es, das sind die Regeln. Ändere dies nicht ohne Grund. Nutze hier diesen Ansatz. Lies hier zuerst die Dokumentation. Prüfe nach Änderungen den Build. Fass diesen Ordner nicht an. Erfinde keine neue Entität, wenn schon eine existiert.

Ich mag diese neue Schriftform. Mein Vater schrieb Geschichten, um seine Welt zu bewahren und weiterzugeben. Heute schreibe ich manchmal nachts Markdown-Anweisungen, damit morgens eine unbekannte KI-Instanz mein Projekt versteht. Der Abstand zwischen beiden Handlungen scheint riesig, manchmal aber fast nicht vorhanden. Wir tun immer dasselbe: Wir versuchen, Kontext an die weiterzugeben, die nach uns kommen.

Branches

Am meisten erschreckte mich früher wohl das Wort branch. Ein Zweig. Jetzt verstehe ich endlich, warum der Baum eine so beständige Metapher ist. Auch das Leben verläuft fast nie geradlinig. Es gibt den Hauptbranch, ein Experiment, eine Version, in der du alles ändern wolltest, eine, die ein Fehler war, und eine, die du noch nicht mit der Hauptlinie verbinden magst. Und bestimmt einen zwei Monate alten vergessenen Branch, bei dem du irgendwann nicht mehr weißt, wer ihn warum angelegt hat.

Manchmal ist das buchstäblich dein Leben.

main — Moskau.

dubai — 2022.

real-estate — 2026.

ai-orchestration — zweigte vielleicht viel früher ab, wuchs aber lange unbemerkt.

personal-brand — ist noch immer in aktiver Entwicklung.

Und irgendwo über all dem liegt ein riesiger Branch family, der älter ist als die meisten anderen Systeme und eigene, längst nicht immer dokumentierte Deployment-Regeln hat. Ich habe drei Kinder, also verstehe ich immerhin etwas von verteilten Systemen.

Die Schönheit eines Branches: Du musst die heutige Welt nicht zerstören, um die morgige auszuprobieren. Du kannst abzweigen, prüfen, irren, umdenken, zurückkehren oder eines Tages das Ergebnis ansehen und sagen: Ja, diese Version ist besser. Merge.

Und was gestern ein Experiment war, wird Teil der Hauptgeschichte. Treffen wir so nicht die meisten wichtigen Entscheidungen? Zuerst existiert das neue Leben getrennt. Du probierst es vorsichtig an: neues Land, neuer Beruf, neue Rolle, neue Arbeitsweise. Dann kommt ein Tag, an dem formal niemand den Rückweg geschlossen hat, du aber weißt: Das ist kein experimenteller Branch mehr. Das ist main.

Und irgendwo liegt noch immer Cherry-Pick

Viele Jahre später verstand ich endlich auch jenen Yandex-Backendler. Er weihte mich nicht in verbotene Magie ein. Cherry-pick bedeutet ungefähr: Du musst nicht die ganze fremde Geschichte übernehmen; manchmal genügt eine benötigte Änderung daraus.

Das ist für mich auch jenseits des Programmierens eines der nützlichsten Prinzipien. Du musst nicht vollständig jemand anderes werden. Manchmal reicht ein guter Commit.

Vom Vater die Fähigkeit, in einem gewöhnlichen Tag eine Geschichte zu sehen. Vom Produktdesign die Gewohnheit, ein System zu suchen. Von der Maklerarbeit Aufmerksamkeit für Preis, Ort, Zeit und den konkreten Menschen gegenüber. Von Programmierern Git. Von KI Geschwindigkeit. Von Dubai den fast krankhaften Glauben, man könne die Zukunft erst vorstellen und dann physisch bauen.

Cherry-pick.

Den passenden Commit in den eigenen Branch.

Und weiter geht’s.

Ein Commit ändert draußen aber noch nichts

Auch das war eine wichtige Entdeckung für mich. Du kannst lokal beliebig viel committen. Das Projekt ist wunderbar, die Geschichte sauber, die Änderungen festgehalten. Solange du aber keinen pushgemacht hast, existiert all das nur auf deinem Rechner, in deiner lokalen Version der Welt.

Hier wird ein rein technisches Wort plötzlich fast schmerzhaft menschlich. Denn den Zustand vor dem Push kenne ich sehr gut. Lange arbeiten, vorbereiten, überarbeiten, durchdenken, perfektionieren. Eine Website bauen. Einen Artikel schreiben. Eine Positionierung ausdenken. Ein Produkt entwickeln. Ein Video drehen. Eine Karte neu zeichnen. Noch etwas verbessern. Noch einmal prüfen. Noch niemandem zeigen.

Die meisten Menschen haben ein riesiges lokales Repository unerledigter Dinge push.

Bei Designern ist es vermutlich besonders groß. Wir können in einer abgeschlossenen Figma schöne Dinge machen. Das Ergebnis hinauszuschicken und anzuerkennen, dass es nicht mehr nur uns gehört, fällt viel schwerer.

Vielleicht gefiel mir deshalb diese kurze Verbindung so sehr: committen und pushen. Erst festhalten, dann hinausschicken. Warte nicht auf die endgültige Projektversion oder deine eigene. Es wird sie nicht geben; Git setzt überhaupt keine endgültige Version voraus. Vielleicht ist das seine wichtigste Weisheit.

Es gibt nur die aktuelle.

HEAD.

Übrigens ein sehr guter Name. Der Punkt, an dem dein Kopf gerade ist. Alles davor ist schon Geschichte. Alles danach existiert noch nicht.

Manchmal gibt es einen Konflikt

Natürlich. Es wäre verdächtig, wenn ein dem Leben so ähnliches System ohne Konflikte auskäme. Du änderst eine Zeile, jemand anderes dieselbe, und beide Versionen beanspruchen Wirklichkeit. Git hält an und sagt: Entscheide selbst.

Das gefällt mir sehr. Es tut nicht so, als kenne es die richtige Antwort. Hier ist eine Wahrheit, dort eine andere; automatisch zusammenführen kann man sie nicht. Genau hier wird der Mensch gebraucht — am Konfliktpunkt.

Das scheint mir eine gute Antwort auf viele KI-Diskussionen. Je mehr Prozesse Maschinen ausführen können, desto deutlicher werden die Stellen, an denen nicht die Produktion einer weiteren Variante gefragt ist, sondern die Wahl einer Weltversion. Darum geht es für mich bei KI-Orchestrierung: nicht einen Agenten schneller arbeiten lassen, sondern verstehen, was von allem Erarbeiteten in Folgendes gehört: main.

Git hat mein Verhältnis zu Fehlern verändert

Im normalen Leben fühlt sich ein Fehler oft wie Zerstörung an: Du hast das Falsche getan, jetzt ist alles verdorben und der frühere Zustand muss irgendwie wiederhergestellt werden. In der Versionsverwaltung wird ein Fehler Teil der Geschichte. Ist die Geschichte gut gespeichert, sind Experimente weniger beängstigend.

Man kann sich den diffansehen, genau erkennen, was sich geändert hat, die Vergangenheit wiederherstellen, einen neuen Branch anfangen oder eine schlechte Entscheidung zurücknehmen. Das gibt erstaunliche Freiheit. Nicht Fehlerfreiheit — die verspricht Git nicht. Es gibt etwas viel Nützlicheres: Umkehrbarkeit.

Produktdesign lehrte mich jahrelang, Oberflächen zu prototypisieren. Git lehrte mich unerwartet, die Wirklichkeit zu prototypisieren.

Manchmal öffne ich abends das Terminal auf dem MacBook, vor dem Fenster liegt Dubai. Die Stadt selbst wirkt wie ein Projekt, das jemand viel zu lange in einem experimentellen Branch entwickelte und eines Tages völlig wahnsinnig in Folgendes zu mergen wagte: main.

Ich lebe jetzt auf Palm Jumeirah, einem Ort, der diesen Gedanken besonders gut erklärt. Erst war eine Idee, dann eine Linie auf dem Plan, ein Ingenieurmodell, danach begannen Menschen buchstäblich, Sand ins Meer zu schütten. Ich kann mir kaum einen anschaulicheren git push menschlicher Absicht in die physische Wirklichkeit vorstellen.

Was Information war, wurde Geografie.

Tagsüber bespreche ich vielleicht eine Villa: Fläche, Preis, Lage, Rendite, Koordinaten, Übergabetermin. Eine Stunde später öffne ich das CRM und bitte einen Agenten, die Mechanik der Objektkarte zu ändern. Dann prüfe ich den diff, lehne die Hälfte der Änderungen ab, bitte um Korrektur, committe und pushe. Abends schreibe ich einen Text. Das alles fühlt sich aus irgendeinem Grund nicht mehr wie völlig verschiedene Berufe an.

Makler, Designer, Autor, KI-Orchestrator. Früher wollte ich ein Wort finden, das alles erklärt. Heute glaube ich, dass das gar nicht nötig ist. Git versucht auch nicht, ein Projekt mit einer Datei zu erklären. Es bewahrt die Änderungsgeschichte.

Vielleicht funktioniert ein Mensch ähnlich.

Wir sind kein Substantiv. Wir sind log.

git status

Es gibt noch einen Befehl, den ich besonders liebgewonnen habe: git status. Er baut, repariert und erschafft nichts. Er sagt nur, wo du gerade stehst, was geändert wurde, was zum Commit bereit ist, was noch draußen liegt und was im Projekt überhaupt passiert.

Manchmal denke ich, auch einem Menschen täte ein Befehl wie git status. Ohne Motivationsbücher, Strategiesitzungen und den Versuch, sofort die nächsten zehn Jahre zu entwerfen. Einfach anhalten und schauen: Wo bin ich, was hat sich in mir geändert, was ist bereit, festgehalten zu werden, was hängt unfertig herum, was sollte längst gelöscht sein, was gehört in .gitignore, und was sollte endlich hinausgeschickt werden.

12. August 2026. 15.208. Lebenstag. 1.474. Tag in Dubai.

Einst saß ich bei Yandex und hörte „Cherry-Picken“ wie den Namen eines unbekannten Rituals. Heute arbeiten mehrere künstliche Agenten gleichzeitig neben mir, und ich schimpfe, wenn einer aufgabenfremde Dateien anfasst. Die Welt verändert den Wortschatz eines Menschen erstaunlich schnell.

Interessanter ist aber etwas anderes: Manchmal kommt ein Wort aus einem sehr engen Fachgebiet und benennt plötzlich etwas, das es schon immer gab.

Wir haben immer Commits gemacht. Wir nannten sie nur nicht so.

Der erste Tag in einem neuen Land: Commit. Die Geburt eines Kindes: Commit. Eine Firma verlassen: Commit. Neuer Beruf: Commit. Umzug: Commit. Der Entschluss, nicht mehr nur Designer zu sein: Commit. Der Moment, in dem KI keine bloß benutzte App mehr ist, sondern eine neue Umgebung zum Bauen: noch ein Commit.

Im Leben reicht Committen aber nicht.

Man kann eine riesige innere Geschichte leben und sie niemandem zeigen. Sich endlos darauf vorbereiten, jemand zu werden, lokal ein perfektes Produkt bauen, einen wunderbaren Text als Entwurf schreiben, ein Video drehen und in Photos lassen, eine nie geöffnete Website erstellen oder ein neues Leben ausdenken, das ewig experimenteller Branch bleibt.

Deshalb ist mir heute der zweite Teil des Zauberspruchs sogar wichtiger als der erste.

Pushen

Schick die Änderungen dorthin, wo der Rest der Welt ist. Es soll ein remotegeben. Die fremde Review soll beginnen. Jemand soll widersprechen. Ein Konflikt soll entstehen. Etwas soll sich als korrekturbedürftig erweisen und den nächsten Commit verlangen.

Das ist Bewegung.

Vielleicht antworte ich deshalb heute gern mit zwei Wörtern, wenn ein Agent fertig ist und nach dem nächsten Schritt fragt. Darin liegt etwas fast Väterliches: Ein Älterer schickt einen Jüngeren auf die Reise und erklärt die Welt nicht lange, weil der Weg sie ohnehin besser erklären wird.

Committen und pushen

Bewahre, was du geändert hast, und behalte es nicht nur für dich.