Working in a Shared Codebase Without Stepping on Each Other

On a busy day, several streams of work happen in our codebase at the same time. One person improves an admin module while an AI session works on a different feature and another fixes a bug in a shared service. Concurrency is how a small team gets a lot done. It is also how changes collide, overwrite each other or get swept into the wrong commit.

We follow a set of habits that keep shared work safe. None of them are complicated; they just have to be consistent.

Commit only your own files

Version control makes it easy to commit everything that changed in a working folder at once. In a shared environment, "everything that changed" may include someone else's unfinished work. So we stage and commit explicit paths: the specific files our own change touched, and nothing else.

If an unfamiliar file appears in the working folder, we leave it alone. It belongs to someone, and they will commit it when it is ready.

Never discard what you did not create

Commands that reset a working folder, discard changes or force a branch to match another can erase hours of someone's work in a second. We treat them as dangerous. Before discarding anything, we look at what it is and whose it is. If it is not ours, we do not touch it.

Pull before starting, merge deliberately

Before starting work, we bring our copy of the code up to date with the shared main branch. When incoming changes overlap with ours, we merge them deliberately, reading each conflict rather than accepting one side automatically. A careless merge can quietly revert someone else's fix.

Small pushes, often

Large batches of changes are harder to review, harder to merge and harder to undo. We push small, complete changes frequently. Each one goes through the same pipeline, so problems are caught while the change is fresh and the person who made it still remembers why.

Respect ownership boundaries

Each module has an owner. When our work needs a change in someone else's module, we coordinate with that owner or follow the module's established patterns, rather than reshaping it to suit one feature. That keeps modules coherent and avoids surprising the people responsible for them. You can read more in why every module has a named owner.

Leave notes for the next person

Concurrent work is easier when everyone can see what is in progress. Handoff notes record what each piece of work touched, what remains and what must not be changed without coordination. When two streams of work might overlap, the notes make that visible before it becomes a conflict.

Shared environments need extra care

Some resources are shared beyond the code: browser sessions used for checks, configuration files, local tools. We avoid changing shared settings as a side effect of our own task. If a shared resource needs to change, that change is its own deliberate decision, communicated to the people who depend on it.

Commit messages that explain

A commit message should say what changed and why, in plain language. Months later, when someone wonders why a line exists, the commit history should answer them. Messages like "fix" or "updates" help no one.

Tools that ask before they act

We also choose tools and settings that ask before doing anything destructive. Version control commands that rewrite history or discard changes require explicit, deliberate use. Credential prompts are turned off for automated tools, so a missing permission produces a clear error instead of a stalled session waiting for a password nobody will type. Hooks and checks that guard commits are respected rather than bypassed; if one fails, the cause is investigated and fixed.

When something does go wrong

Even with good habits, collisions sometimes happen. Two changes touch the same lines, or a merge reverts something it should not have. When that happens, the first step is to stop and look, not to force a resolution. The commit history shows what each change intended, and the people involved can decide together what the correct result is. A few minutes of careful reconstruction is better than a fast fix that loses someone's work.

The result

These habits let many people and assistants work in parallel without losing each other's progress. They are easy to state, easy to check and, once habitual, nearly invisible. Their absence is very visible: lost work, broken releases and long afternoons untangling merges.

Frequently asked questions

How do you avoid committing someone else's changes?

Stage and commit only the specific files your change touched, and leave unfamiliar files for their owners.

Is it safe to reset a working folder to clean it up?

Only after checking what would be discarded. Resetting can erase other people's unfinished work in a shared environment.

Why push small changes frequently?

Small changes are easier to review, merge and undo, and problems are caught while the change is still fresh.