The Sync Routine Step Seven Nearly Shipped Our Whole Develop Branch

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

We had run the usual update command to bring an urgent production repair up to date. It was getting ready 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. We 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 means combining one pile of code with another. Here, the pile called develop was where work in progress lived. It could hold features that were not ready, experiments, and changes that still needed more checking. The repair we were 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 carried its reassuring version number. That label would not have made the extra work safe.

The routine did what it was built to do

The first thing we 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 this particular repair had different rules. It followed its normal path because that was the most reasonable path it could see.

We had walked in assuming the routine already handled repairs like this one. Our plan for the session was to run it and then merge the live version back into the repair, and we said so in our first message. Then we read what the routine would actually run. Step seven was a hardcoded merge of develop into whatever copy we were standing on. Our 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. We stopped mid-session to trace a helper that had applied one broad rule where a narrow one was needed. We could not safely continue until we understood it.

A second problem 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 we 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.

We 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.

One line with a long reach

While fixing that, we 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 we usually opened that same copy. When we used a different one, the helper tried to work on the wrong project. A tool should act on the place you are in, not a place it remembers from an old day.

The same gap in another helper

The same pattern showed up in a helper we use when opening a ticket to investigate. It used to open a blank web page and wait for us 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 we opened an investigation, plus one more small thing to hold in our heads.

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

A helper does not need to be clever enough to guess the unwritten rules of your work, and we 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 names beginning with hotfix/ skip the develop merge. It no longer has to, because that rule now lives in a file next to step seven, where the routine reads it before running, instead of in a habit we hoped to remember during an urgent repair.

If you have tools that touch your live site, find out whether they know the difference between an urgent repair and unfinished work, or whether that rule exists only in someone’s head. Write it down where the tool reads it before it runs, and make the tool stop and ask when it cannot tell which path applies.

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/everyday-ai/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.