Design Manager Edits vs. GitHub Deployments
Three developers maintain a HubSpot CMS theme for a media company with 180,000 monthly visitors. The theme is in a GitHub repo and connected to the portal through GitHub integration; pushes to main deploy automatically. Developers also use the HubSpot CLI (hs watch, hs upload) against a sandbox. Two content designers have Design Manager access and routinely edit module HTML and fields.json directly in the production Design Manager to fix typos or tweak spacing. Last week a developer deployed a newsletter module from the repo and overwrote a designer's production fix; the next day a designer's edit overwrote a field label change. The team now has inconsistent module files between repo, sandbox, and production. They want a reliable source of truth without blocking quick content fixes.
1. Diagnose the root cause and propose an ownership model for theme code.
Read the worked answer
The root cause is that production theme files have two independent writers: the GitHub deployment pipeline and the Design Manager. GitHub integration deploys the repository state; it does not merge with whatever a designer changed in the portal. A designer's direct edit lives only in the portal until someone fetches it, and the next deploy can overwrite it. Likewise, a repo deploy can overwrite a portal hotfix. The sandbox adds a third state if it is refreshed inconsistently.
The ownership model should be: the Git repository is the source of truth for module HTML, CSS, JS, templates, and fields.json. Developers change theme code only through branches and pull requests. Content designers own page content, not theme files. Design Manager access should be restricted to developers, or at minimum write access should be removed for content roles. Quick content fixes should happen in the page editor or a module field, not by editing module source. If a designer genuinely needs a spacing tweak, it should be a field or a CSS class controlled by the theme, not a one-off portal edit.
2. Outline a migration and day-to-day workflow to get repo, sandbox, and production back in sync.
Read the worked answer
First freeze Design Manager edits and announce a short code freeze. Fetch the production theme with the CLI into a branch, then diff it against the repo. Every difference is either an intended repo change that never deployed or a portal hotfix that must be preserved; review them one by one, do not blindly take either side. Commit the merged result, deploy it to the sandbox, and click through the highest-traffic templates. Only then merge to main so GitHub integration deploys production.
Day to day: developers work locally with hs watch against the sandbox; pull requests require review; main deploys production. Designers request changes through tickets or module fields. If someone must edit in Design Manager during an incident, they immediately fetch that file, commit it, and open a PR so the repo catches up. Add a scheduled or pre-deploy check that fetches production and alerts on drift. The goal is not to ban emergency edits; it is to make sure every portal edit becomes a commit before the next deploy.
3. What would you do for an urgent production typo at 4:55 p.m. on Friday?
Read the worked answer
I would still use the repo, but shorten the path: create a hotfix branch, change the file, get a quick review from whoever is available, and deploy. If the typo is customer-facing and a PR truly cannot happen, a Design Manager edit is acceptable as an emergency action, but it must be followed immediately by hs fetch of that file into a branch and a commit. The commit should reference the incident so the next deploy does not silently revert it. After the fix, check that the production file and repo file match. The dangerous outcome is not the emergency edit itself; it is leaving production as the only copy. I would also note the access exception and revisit why a content-level typo required theme code, since that usually means a label or field is hard-coded where it should be editable.