A Routine Branch Update Almost Mixed Unfinished Work Into an Urgent Hotfix

The cursor sat still beside the words develop and hotfix/<version> in the middle of a work session on April 22.

I had run the usual update command to bring an urgent production repair up to date. Instead, it was preparing to mix a whole pile of unfinished work into a change that was supposed to fix one problem and go straight to the live site. I caught it before it happened, but the pause was sharp. An urgent repair is not the time to wonder what else you have accidentally packed into the box.

The technical word is merge. It just means combining one pile of code with another. In this case, the pile called develop was where work in progress lived. It could contain features that were not ready, experiments, and changes that still needed more checking. The repair I was working on had started from the live version instead.

Putting the unfinished pile into that repair would have turned a small, focused fix into a delivery truck for whatever happened to be sitting in the work area that afternoon. The repair would still have had its reassuring version number. That label would not have made the extra work safe.

The first thing I tried was the ordinary sync routine, and that was the problem. It knew there was a live version and a work-in-progress version. It did not know that this particular repair had different rules. It followed its normal path because that was the most reasonable path it could see.

I had walked into it assuming the routine already handled repairs like this one. My plan for the session was to run it and then merge the live version back into the repair, and I said so in my first message. Then we read what the routine would actually run. Step seven was a hardcoded merge of develop into whatever copy I was standing on. My answer was that we would never merge develop into a hotfix, so the script had to be fixed before anything else.

The cost was time. I stopped mid-session to trace a helper that had applied one broad rule where a narrow one was needed. I could not safely continue until I understood it.

There was a second problem hiding in the same routine. Once an urgent repair goes out, the normal release process carries that repair back into the ongoing work in a particular order. The old routine tried to do part of that job on its own as well. That could create a duplicate entry in the record of what changed, like writing the same appointment twice on a paper calendar. Nothing useful is added. The extra mark only makes the next person wonder which entry is real.

So I changed the update helper to read the beginning of the work copy’s name before it decided what to do. Copies marked as urgent repairs now follow their own path. They do not pull in the unfinished pile. They do not repeat a handoff that the normal release process already performs. They update only against the place they actually came from. The main work copies still have their own rules, and everything else follows the original route.

I also put the rules where the helper could read them. Before, the layout of the work was visible, but the meaning was mostly assumed. You could see several copies of the project, just as you can see several labeled drawers in a filing cabinet. You could not tell, from the labels alone, which papers were allowed to move from one drawer to another. That part was policy, and policy that exists only in someone’s head is not a rule a tool can follow.

While fixing that, I found one more small trap. The update helper had a folder location typed into it for a particular copy of the project. It worked only because I usually opened that same copy. When I used a different one, the helper tried to work on the wrong project. It was one line, but it was one line with a long reach. The fix mattered because a tool should act on the place you are in, not a place it remembers from an old day.

The same lesson showed up in another helper I use when opening a ticket to investigate. It used to open a blank web page and wait for me to find and paste in the page where the problem could be seen. The ticket already had a links field for exactly that purpose. That old approach cost about two minutes every time I opened an investigation, plus one more small thing to hold in my head.

Now the helper reads the link when the ticket opens. If there is one, it goes there. If there is not, it asks. The improvement is not magic. It simply uses information that was already written down.

That is the part I keep coming back to. A helper does not need to be clever enough to guess the unwritten rules of your work. I should not expect it to. It needs a clear instruction about which drawer it may open, which one it must leave alone, and when it has to stop and ask.

The helper still cannot invent the rule that hotfix names beginning with hotfix/ skip the develop merge, but it no longer has to, because that rule now lives in a file next to step seven where the routine reads it before running, not in a habit I hoped to remember on a hotfix repair.

dxdev LESSON · paste into your AI coding agent
LESSON: A sync helper needs to know a hotfix branch's rules are different before it runs, not after
SOURCE: dxdev.com/blog/2026-04-22_update-that-was-about-to-bring-the
WHAT HAPPENED: A routine branch-update command was about to merge the full unfinished develop branch into an in-progress production hotfix, because the sync tooling had one hardcoded path, merge develop in, that didn't distinguish a hotfix branch, started from live or master, from a normal feature branch, started from develop. It was caught before it ran. The fix made the helper read the branch name's prefix and follow a narrower path for hotfix branches: no develop merge, and no duplicate back-merge step that the normal release process already performs later. A separate hardcoded folder path in the same helper caused it to silently operate on the wrong project when run from a different clone.
THE RULE: A shared automation helper that assumes one branch topology for every branch will eventually be asked to run against a branch whose rules are different. Make the helper read the branch's own type from its name before choosing a path, rather than hardcoding a single behavior for everything.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any git or sync automation script with a single hardcoded merge or update path applied to every branch, without branching logic based on the branch name or type, such as hotfix versus feature.
  2. Any automation script with a hardcoded absolute folder path for "the project," instead of resolving the current working directory or repo root dynamically.
  3. Any automation step that duplicates part of a process, such as a back-merge or handoff, that a separate, later stage in the release pipeline already performs, risking a duplicate record.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.