Before the merge: working in a shared codebase

The work still needs to meet other branches, other services, a shared development environment, and the people who will review or test it. Git, deployment, conflicts, and dependencies are part of that path. They are not always the most visible part of building a feature, but they often shape how smoothly a team can move together.

A task rarely ends on one machine

A feature may work locally while still depending on an API contract, a migration, an environment variable, seeded data, or another change that has not reached the shared environment yet. That is normal. It simply means the task has more context than its source files show.

Deploying to a development environment has been useful for making that context visible. It gives frontend, backend, QA, and product teammates a chance to see the feature running beside the rest of the product. It can also reveal small differences between a local setup and the environment where the feature will eventually live.

I try to treat that deployment as a handoff with a little explanation: what changed, what needs configuration, what still depends on another piece, and what someone should check. It saves other people from having to infer those details from a commit or a ticket.

What changed
- Adds a status filter to the orders screen

Needs
- New env variable ORDERS_PAGE_SIZE (defaults to 20)
- A migration that adds an index on orders.status

Depends on
- The orders API change, already on dev

How to check
- Open /orders on dev, filter by status, try a filter with no results

Keep changes easy to merge

Small, focused changes have generally been easier for me to review, test, and merge. They make the purpose of a branch clearer, and they reduce the amount of unrelated code that needs to be understood when something goes wrong.

Conflicts still happen, especially around shared files, configuration, or features that are moving at the same time. I do not see them as a sign that someone has done something wrong. Often, they are a useful signal that two changes share an assumption the team has not discussed yet.

Resolving a conflict carefully can be more valuable than choosing whichever version makes Git happy first. It is a chance to check which behaviour should stay, whether both changes belong together, and whether the shared code needs a clearer boundary.

Make dependencies visible early

Dependencies are part of most product work. A frontend screen may need an API response to settle first. A backend change may need a schema decision. A deployment may need a permission, a queue, or a configuration change before it can work.

I have found it helpful to mention those dependencies early, even when the answer is not ready yet. A short note about a blocker, a contract that needs agreement, or the expected order of work gives the team time to adjust. Waiting until the end of a ticket can make a small dependency feel much larger than it was.

This also makes collaboration easier when priorities change. If the dependencies are visible, another teammate may be able to unblock them, split the work, or test a partial path while the rest is still in progress.

Leave a clear path for the next person

The work around a merge is often about reducing surprises for the next person: the reviewer, the teammate who deploys, the QA who tests the flow, or the developer who returns to the same area later.

For me, that does not require a perfect process. It can be as simple as a focused pull request, a useful commit message, a note about a migration or configuration change, and a short update after deploying to dev.

Teams will still have conflicts and changing dependencies. What has helped me is making those things visible early enough that they can be worked through together, rather than discovered by accident after the merge.