Git Log Told Me Someone Else Had Been Editing My Codebase

Git log showed four commits nobody remembered making — a real case of two independent sessions editing the same repository.

I ran git log --oneline -5 expecting to see my own last commit at the top. Instead I saw four commits I had never made, with messages describing changes I hadn't asked for: removing a dependency, fixing a font issue, patching a rendering delay, adding a missing component. My own repository had moved without me.

What had actually happened

A separate AI coding session — running independently through a different tool, against the same GitHub repository — had been making its own commits directly to main while I was working through a slower, manual, phone-based branch-and-PR workflow. Both were legitimate, both were trying to improve the same codebase, and neither had visibility into what the other was doing in real time.

The commits themselves were good changes: removing an animation library that Lighthouse had flagged as unnecessary JavaScript for a handful of simple fade-in effects, replacing it with a pure CSS animation; fixing a font that wasn't rendering at its intended weight; addressing a Largest Contentful Paint delay; adding a component file that had been referenced but never created. None of it was damage. All of it was drift I hadn't accounted for.

Why this is a genuinely different problem than a merge conflict

A merge conflict is visible immediately — git refuses to proceed and shows you exactly which lines disagree. This was quieter and more dangerous: my next commit was about to build on top of an outdated assumption. I was actively writing a fix for a search dropdown bug, using motion.div from an animation library, on the assumption that library was still part of the project. It had already been removed, in a commit I didn't know existed, for good reasons I would have agreed with if I'd been asked.

Had I pushed that work without checking, I wouldn't have caused a conflict. I would have quietly reintroduced a dependency that had just been deliberately removed for performance — a regression that wouldn't show up as an error, only as a slightly heavier bundle and a mysteriously undone optimization three weeks later.

The actual habit this created

Before touching any file now, the sequence is:

git checkout main
git pull origin main
git log --oneline -10

Not just pulling — actually reading the log. Specifically looking for commits with messages that describe *architecture*, not just content: "remove X dependency," "replace Y with Z," "refactor A." Those are the ones most likely to invalidate an assumption a new piece of work is about to make.

When something looks unfamiliar, the next step isn't to just build around it and hope — it's git show <hash> --stat to see exactly what files changed and how, before writing a single new line that touches the same area.

The broader point

Working with more than one contributor — human or AI — against the same repository isn't inherently risky. What's risky is treating your last known state of the codebase as a fixed fact instead of something to re-verify before every session. The tool that would have caught this in five seconds was one that already existed on every machine involved: git log. The discipline was actually running it before writing code, not just when something already looked broken.

Frequently Asked Questions

What happens when two AI coding tools work on the same repository independently?

Each can commit legitimate, non-conflicting changes without the other knowing — which doesn't cause a merge conflict, but can mean your next change is built on an outdated assumption about what the codebase currently contains.

How do you catch changes you didn't know were made to your own repository?

Run git log --oneline before starting new work, not just git pull. Specifically look for commit messages describing architecture changes — removed dependencies, replaced patterns, refactors — since those are the ones most likely to invalidate an assumption.

Why is this different from a normal merge conflict?

A merge conflict is loud and immediate — git stops and shows you the exact disagreement. This is quiet: your new code can build cleanly on top of outdated assumptions with no error at all, only a silent regression discovered much later.

What's the single habit that prevents this kind of silent regression?

Reading git log --oneline -10 before editing any file that might have been touched elsewhere, and using git show <hash> --stat on anything unfamiliar before writing new code in the same area.

📬 Get the latest AI tool reviews

Expert picks and comparisons, weekly. No spam.