Git, Branches and Environments
Follow a change without confusing review, staging, and production. · Technical Fluency · Lesson 26 · 3 min
Git, Branches and Environments · 3 min
Situation
“It’s merged” does not mean users have it.
An engineer merges a change, design approves it on staging, and support still sees the old behavior in production.
These statements can all be true. Source history, deployment environment, and feature availability describe different parts of delivery.
Mental model
Git records changes to source.
A repository contains the project's versioned files and history. A commit records a particular change. A branch supports a line of work. A pull request proposes and reviews changes before integration.
These tools help teams coordinate and inspect what changed. A merged pull request does not itself establish that the change has been deployed successfully.
Environments
The same product can run in several places.
Local runs on a developer's machine. Staging provides a shared environment for validation. Production serves real users.
Configuration, data, dependencies, and enabled features can differ between them. A bug that does not reproduce locally may still be real because those conditions differ.
Example
Track one release clearly.
Record the change under review, its expected behavior, the staging URL, and the deployed version. Confirm which accounts or flags expose it.
When reporting a defect, include the environment and version if known. “It worked yesterday” becomes much more useful when tied to the actual code and configuration that were running.
Failure case
Using production data casually in staging.
Real customer data can carry permissions and privacy requirements that a test environment does not satisfy. Use appropriate synthetic or approved test data and realistic shapes.
Also test migrations and compatibility. A clean staging database may hide problems that appear only when old production records meet the new code.
Remember this
Ask which version runs where, for whom.
That question connects code review, validation, deployment, and rollout. It avoids mistaking one delivery milestone for the whole release.