← All posts
← →

Who keeps reverting my commits: the game designer who clicked “No”

2013

Steam Defense was my first project on git. Before that I had worked with SVN, where branches weren’t something we used. So here too everyone committed to a single branch, master.

Our configs were written in C#; I’ve already written how they worked. I edited them too, adding new types and parameters. Then I noticed my changes were being rolled back. Once, twice. I checked the history: it was the game designer.

I went over and asked him why. He was surprised: he wasn’t reverting anything, just working on the configs.

So I simply stood behind him and watched how he worked. He writes code in a config and clicks “Update”. Fresh changes come in, mine among them, including in the very file he has open. But that file isn’t saved; his version lives in the editor’s memory, and there was no autosave back then. The editor asks: the file has changed, reload it? He answers “No” and carries on with his old version. Then he saves and pushes on top. Git sees no conflict at all: it’s an ordinary new commit that simply doesn’t have my lines.

That’s how he erased my changes without having any idea what was going on. And it wasn’t his fault: the dialog asks about a file, not about someone else’s work, and “No” looks like the safest answer.

What I took from it: when changes vanish and everyone says they did nothing, don’t argue — stand behind the person and watch how they work. And one shared branch for everyone forgives such mistakes far worse than separate branches with a review before merging.