Commit and Push

12 August 2026 · Dubai, UAE
25.2048° North · 55.2708° East · UTC+4
Day 15,208 of life · Day 1,474 in Dubai

A long time ago, in what now feels like another life, a backend engineer at the Yandex office tried to explain to me that sometimes you had to cherry-pick something from one branch into another.

I listened carefully. I always tried to listen carefully to programmers, because judging by their faces, they were clearly discussing matters of enormous importance. Somewhere there was a tree. The tree had branches. Commits happened on those branches. Sometimes the branches had to be merged. Sometimes they could not be merged, in which case something had to be cherry-picked. In especially difficult cases, there was a conflict.

To me, a product designer, all of this sounded like some form of ancient Kabbalah. I understood interfaces, user flows, information architecture. I could argue for hours about why a user would click here rather than there, why one button needed to move eight pixels to the left, or why a product team had spent three months designing something nobody actually needed. I could design a fairly complex system and explain how it should behave across a hundred different states. But eventually there came a boundary. Beyond it lived the programmers.

I handed them Figma, they disappeared into their terminals, and another physics took over. There were repositories, containers, environments, endpoints, migrations, keys, and the mysterious thing called Git. I remained on my side of the river. I assumed this was simply how the universe had been arranged: the designer designs, the programmer builds. The architect draws the map, and someone else eventually has to walk into the forest.

Years passed. I moved to Dubai, changed several lives, professions, homes, teams, interfaces, and ideas about who I was. And one day I found myself sitting with a laptop somewhere between a villa viewing in Tilal Al Ghaf, a real-estate call, edits to my own website, children, a dog, a move to Palm Jumeirah, and yet another attempt to build a CRM for my brokerage work — calmly telling an agent: Commit the changes and push.

I looked at the sentence and suddenly realised that something considerably more important had happened than learning another tool.

I had crossed the river.

In the beginning, there was the file

Files have one unpleasant property: they exist only in the present. Veteran designers know this archaeology well — final.fig, final-final.fig, final-v2.fig, final-v2-new.fig, final-v2-new-real.fig. Every new file somehow had to preserve the memory of the previous one. Sometimes the memory lived in the filename, sometimes in an Archive folder, sometimes in the designer's head, and sometimes it vanished altogether. For years, we tried to manage time manually.

Git proposed a completely different way of thinking about the past. You do not need to create another complete copy of the world every time the world changes. You can preserve the change itself: this was here, then I did this, this was the reason, this was the moment when the system became something else. And that moment is called a commit.

It took me many years to feel the beauty of that word — not its technical beauty, but something almost metaphysical. A commit is a promise made to reality. You are saying: this is the state of the world I am prepared to stand behind right now. Before that, changes may lie scattered around you like debris on a construction site: several files modified, one deleted, another created, logic altered somewhere, while somewhere else an agent has inexplicably rewritten half the project even though nobody asked it to. Everything is still unstable. Everything can still be abandoned.

Then you commit, and chaos receives a name:

fix property card layout, add owner matching, restore auth flow, update agent instructions, stop breaking production.

The last one is particularly important.

And something remarkable happens: the past no longer disappears. It becomes a road.

I used to think memory lived inside the head

Perhaps that is why the subject of memory in neural networks fascinates me so much now. We are used to thinking of memory as a human property. I remember my first office, Moscow, the rooms where we argued about products, and that backend engineer explaining cherry-pick to me, even though I almost certainly understood none of it at the time. I remember 30 July 2022 — the day my own Dubai counter began.

Today is Day 1,474. You could write it another way: Dubai / commit 1474

Almost everything has changed since then: addresses, work, my idea of work, the people around me, the size of my children, the amount of stuff in the house, the number of neural networks inside my laptop, even the definition of who I am. Human memory, however, is unreliable. It constantly rewrites history, and every time we revisit the past, we quietly edit it to fit the person we have become today.

Git behaves differently. Git is remarkably unemotional. It says: this is what existed, this is what changed, this is who changed it, this is when — and this is why, assuming you bothered to write a decent commit message. In a sense, git log may be one of the most honest autobiographies I have ever encountered. No retrospective editing. No attempt to look more intelligent with the benefit of hindsight.

Tuesday, 02:14 — broke authentication

Tuesday, 02:47 — fixed authentication

Tuesday, 03:06 — fixed what I broke while fixing authentication

That is roughly what real life looks like.

Then came the agents

And this is where everything changed completely. The computer used to be a tool: you clicked buttons, moved a mouse, opened an application, and performed the action yourself. Then software became capable of executing commands. Now I open a project and find entities inside it for whom a description of intent may be enough.

One reads the code. Another investigates the architecture. A third fixes the interface. A fourth checks the work of the first. A fifth can write a database migration while I am driving to view a townhouse. Gradually, I am becoming less of a person who performs every movement with his own hands and more of a person who determines the direction in which those movements should happen.

I once designed interfaces between humans and software. Now I design an interface between human intention and a multitude of artificial executors. And suddenly the old vocabulary of programmers has become essential to me.

Because if one person works on something, you can still hope that person remembers. When agents work on it, hope is not a memory system. They need territory, rules, history, and a clear understanding of what may be touched and what must remain untouched. They need context not as intuition inside my head, but as files.

That is how .gitignore entered my life, and I unexpectedly discovered that it might be one of the most philosophical objects in all of software development.

.gitignore is a list of what the world is supposed to forget.

Not everything deserves history. There are temporary files, secrets, garbage, intermediate artefacts, and things that exist only on your machine and have absolutely no reason to travel any further. To preserve memory properly, you first have to decide what should not be remembered. Humanity, I suspect, arrived at that insight considerably later than Git.

And then there is AGENTS.md, along with other files in which you leave instructions for whoever comes after you. Except now, whoever comes after you does not necessarily have to be human. You are literally writing a letter to creatures from the future: this is the project, this is how it is structured, these are the rules. Do not change this without a reason. Use this approach here. Read the documentation first. Run the build after making changes. Do not touch this folder. Do not invent a new entity if one already exists.

I like this new form of writing. My father once wrote stories to preserve his world and pass it forward. Now I sometimes write instructions in Markdown late at night so that, in the morning, some unknown instance of artificial intelligence can understand how my project works. The distance between those two acts of writing appears enormous, and yet sometimes I think there is almost no distance at all. We are doing the same thing we have always done: trying to pass context to whoever comes next.

Branches

Perhaps the word that frightened me most back then was branch. A branch. Now I finally understand why the tree became such a persistent metaphor. Life almost never develops along a single line. There is the main branch, an experiment, the version in which you decided to rebuild everything, the version that turned out to be a mistake, and another version you are still afraid to merge into the main one. And, inevitably, there is some forgotten branch from two months ago that you stumble upon one day and can no longer remember who created it or why.

Sometimes this is literally your life:

main — Moscow.

dubai — 2022.

real-estate — 2026.

ai-orchestration — may have branched off much earlier, but spent a long time growing somewhere out of sight.

personal-brand — still under active development.

And somewhere across all of this runs the enormous family branch, older than most of the other systems and governed by its own deployment rules, many of which remain undocumented. I have three children, so I do, after all, know something about distributed systems.

The beauty of a branch is that you do not have to destroy today's world in order to test tomorrow's. You can branch off, try something, fail, change your mind, return — or one day look at what you have built and say: yes, this version is better. Merge.

What was an experiment yesterday becomes part of the main history today. Isn't that how most serious decisions work? A new life begins as something separate. You try it on carefully: a new country, a new profession, a new role, a new way of working. Then one day arrives when nobody has formally closed the road back, but you already know. This is no longer an experimental branch. This is main.

And somewhere in there, cherry-pick is still waiting

Many years later, I finally understood that backend engineer from Yandex. He had not been initiating me into some forbidden ritual. Cherry-pick means something approximately like this: you do not have to take someone else's entire history. Sometimes you only need one particular change from it.

I think this may be one of the most useful ideas Git offers outside programming. You do not have to become another person in their entirety. Sometimes one good commit is enough.

From my father — the ability to see a story hidden inside an ordinary day. From product design — the instinct to look for the system. From brokerage — attention to price, place, timing, and the actual human being sitting across from you. From programmers — Git. From artificial intelligence — speed. From Dubai — an almost pathological belief that the future can first be imagined and then physically built.

Cherry-pick.

Take the commit you need into your own branch, and keep moving.

But a commit changes nothing outside

That was another important discovery for me. You can commit as much as you like locally. The project may be beautiful, the history immaculate, every change properly recorded — but until you push, all of it exists only on your machine, inside your local version of the world.

And this is where a completely technical word becomes almost painfully human, because I know the state before push extremely well. Spending a long time making something. Preparing it. Reworking it. Thinking it through. Perfecting it. Building the website. Writing the article. Inventing the positioning. Assembling the new product. Shooting the video. Redesigning the card. Improving it just a little more. Checking it one more time. Not showing it to anyone just yet.

Most people have an enormous local repository of pushes they never made.

Designers, I suspect, have an especially large one. We are very good at making something beautiful inside a closed Figma file. Sending it out into the world is harder, because the moment we do, we have to accept that it no longer belongs only to us.

Perhaps that is why I became so fond of this short phrase: Commit and push. First, fix the change in place. Then send it. Do not wait for the final version of the project. Do not wait for the final version of yourself. There will be neither. Git does not believe in final versions either, and that may be its greatest wisdom.

There is only the current one:

HEAD.

A very good name, incidentally. The point where your head is right now. Everything behind it is already history. Everything beyond it does not yet exist.

Sometimes there is a conflict

Of course there is. It would be suspicious if a system this similar to life had no conflicts. You changed one line. Someone else changed the same line. Now both versions are making a claim on reality. Git stops and says: You decide.

I like that very much. It does not pretend to know the correct answer. Here is one truth. Here is another. They cannot be combined automatically. A human being becomes necessary precisely here — at the point of conflict.

That seems to me like a fairly good answer to many conversations about artificial intelligence. The more processes machines become capable of performing, the more clearly we will see the places where what is required is not the production of yet another option, but the choice of which version of the world should exist. That, to me, is what AI orchestration is about. Not making one agent work faster, but understanding which parts of everything they have produced deserve to enter main.

Git changed the way I think about mistakes

In ordinary life, a mistake often feels like destruction: you did the wrong thing, now everything is broken, and somehow you have to restore what existed before. In version control, a mistake becomes part of the history. If the history has been preserved properly, experimentation becomes considerably less frightening.

You can inspect the diff, see exactly what changed, recover the past, start another branch, or reverse a bad decision. That creates an extraordinary kind of freedom. Not infallibility — Git promises no such thing. It offers something far more useful: reversibility.

Product design spent years teaching me to prototype interfaces. Git unexpectedly taught me to prototype reality.

Sometimes in the evening I open the terminal on my MacBook and Dubai is outside the window. The city itself resembles a project that somebody spent far too long developing in an experimental branch before, one day, making the completely unreasonable decision to merge it into main.

I now live on Palm Jumeirah, perhaps the perfect physical illustration of that idea. First there was an idea, then a line on a drawing, then an engineering model, and eventually people began literally pouring sand into the sea. I find it difficult to imagine a more literal git push of human intention into physical reality.

What had been information became geography.

During the day I might discuss a villa: its area, price, location, yield, coordinates, completion date. An hour later, I can open my CRM and ask an agent to change the mechanics of a property card. Then I review the diff, reject half the changes, ask for corrections, commit, push, and write an essay in the evening. Somehow, none of this feels like several entirely unrelated professions anymore.

Broker, designer, writer, AI orchestrator. I used to want a single word that could explain all of it. Now I am no longer sure one is necessary. Git does not attempt to explain an entire project with a single file either. It preserves the history of changes.

Perhaps a human being works in much the same way.

We are not nouns. We are a log.

git status

There is another command I have become particularly fond of: git status. It builds nothing, fixes nothing, creates nothing. It simply tells you where you are: what has changed, what is ready to be committed, what remains outside, and what exactly is happening inside the project.

Sometimes I think a human being could use a git status too. No motivational books, no strategy sessions, no urgent attempt to design the next ten years. Just stop and look: where am I now? What has changed in me? What am I ready to commit? What is still hanging around unfinished? What should have been deleted long ago? What belongs in .gitignore? And what is finally ready to be pushed out into the world?

12 August 2026. Day 15,208 of life. Day 1,474 in Dubai.

Once, I sat in the Yandex office listening to the word “cherry-pick” as though it were the name of an obscure ritual. Now several artificial agents can be working beside me at once, while I get annoyed because one of them has started modifying files that had absolutely nothing to do with its task. The world changes a person's vocabulary with astonishing speed.

But something else is even more interesting. Sometimes a word emerges from a tiny professional niche and suddenly turns out to be the name of something that has existed all along.

We have always made commits. We just didn't call them that.

The first day in a new country is a commit. The birth of a child is a commit. Leaving a company is a commit. A new profession is a commit. Moving home is a commit. The moment you decide to stop being only a designer is a commit. The moment you realise that artificial intelligence is no longer an application you happen to use but a new environment inside which you can build — that is another commit.

But committing is not enough.

You can live through an enormous internal history and never show it to anyone. You can spend forever preparing to become someone, build a perfect product locally, write a beautiful essay and leave it in drafts, shoot a video and leave it in Photos, create a website nobody ever opens, or invent a new life that remains an experimental branch forever.

Which is why the second half of the incantation matters even more to me now.

Push

Send the changes to where the rest of the world exists. Let there be a remote. Let someone else begin a review. Let someone disagree. Let there be a conflict. Let something turn out to need fixing, followed by another commit.

That is movement.

Perhaps that is why, when an agent finishes another task and asks what it should do next, I like answering with two words. There is something almost paternal in them, like an older person sending someone younger out onto the road without trying to explain too much about how the world works, because the road will explain it better anyway.

Commit and Push

Remember what you changed — and don't keep it only to yourself.