Why Directly Fixing Bugs in the Pre‑Release Branch Is a Bad Idea (and the Correct Hotfix Workflow)

Background

During a recent pre‑release regression test a bug was discovered, and I fixed it by directly editing the code in the pre environment without creating a proper branch. This shortcut caused criticism from leadership because it bypasses traceability and makes future rollbacks risky.

Branch Management and Collaboration Process

A typical project uses four environments:

Development (dev) : daily development, integrates feature branches, may be unstable.

Testing (test) : QA regression testing, relatively stable, merged from dev .

Pre‑release (pre) : simulates the production environment, used for final verification before launch, changes should be infrequent.

Production (prod/main) : the final, fully tested release version.

Typical workflow in our company:

Feature development : developers create a feature/xxx branch from dev , complete work, then merge back into dev .

Testing : once the feature stabilizes, merge dev into test for QA. If bugs appear, fix them on a hotfix/xxx branch and merge back into test .

Pre‑release verification : after QA passes, merge test into pre . Any bug found in pre must be fixed on a new hotfix branch created from pre , not by editing pre directly.

Production release : merge pre into prod and deploy.

Why Not Edit Bugs Directly in pre ?

The pre branch is meant to receive only reviewed, approved changes that simulate the live environment. Direct edits obscure code origin, bypass review, cause merge conflicts, and make it impossible to trace which bug originated where.

Correct Hotfix Procedure

Create a hotfix branch from pre :

<code>git checkout pre
git pull origin pre    # ensure latest code
git checkout -b hotfix/fix-button-not-working
</code>

Then:

Fix the bug, run local tests.

Create a merge request to merge the hotfix back into pre after QA approval.

This naming convention makes the purpose of the branch obvious, facilitating tracking, rollback, and management.

Conclusion

Following the described pre‑environment bug‑handling standards ensures reliable releases and maintains clear audit trails. Direct modifications in pre should be avoided in favor of disciplined hotfix branching.