Use GitHub sync and saved versions without losing your work

When reporting a problem, name the artifact you are looking at. ‘The site is broken’ could refer to a retained draft, the current saved preview, a repository branch, or an old deployment. Include the safe version date or branch name and the failing route. This avoids correcting the wrong copy and makes it easier to verify that the recovery reached the destination you actually use.

A saved Uvilno version is a completed website result you can review and restore. A Git commit records repository content and history. A recoverable build draft may contain completed private files from an unfinished run but has not necessarily passed verification. These are useful recovery tools with different guarantees. Before choosing one, identify whether you are recovering a design direction, synchronizing code changes, or inspecting work from an interrupted build.

Keep a small record of the current release: the saved version, repository and branch if connected, and deployed URL. That gives you a stable reference when a later revision fails. A preview that looks correct is not proof that a repository has been updated, and a successful push is not proof that an external host deployed the right output. Treat each boundary as an action with its own result to verify.

Uvilno uses an authenticated GitHub authorization popup for the supported repository connection. Review the provider consent page and requested access before continuing. GitHub recommends checking the application identity and the information it requests. Repository access and a builder account are related but distinct permissions; do not assume that clicking a familiar provider logo is merely a harmless visual preference. Use the intended GitHub account and confirm any organization restrictions that apply.

Never paste a personal access token into chat or generated code to repair a connection. The supported flow keeps sensitive authorization on the trusted server. If consent is cancelled or the popup fails, the interface should report the real connection state and offer reconnection. Existing repository access may be affected by revocation or organization policy. Check authorization rather than repeatedly initiating a source operation that cannot succeed with the current permission grant.

A repository import is more than attaching a text reference. It needs a supported project shape, bounded source, reproducible dependencies, and an isolated build or preview path. Uvilno supports its documented static and compatible frontend import workflows, including supported Vite and Next.js static-export projects. That is not a promise that any arbitrary server application, deployment script, or monorepo can run unchanged. Inspect the import result and the runtime it reports.

Choose the repository and intended branch carefully. Review what the project contains before bringing it into an AI workflow, especially environment files, private data, and generated artifacts. Keep secrets out of the imported source and configure needed services through trusted mechanisms. After import, open the actual preview, test routes and interactions, and record any unsupported dependency. A successful file read does not establish a successful build, and a successful compile does not establish the application's main behavior.

Connecting GitHub does not bypass Uvilno's source entitlement. Generated files stay private until the project has its permanent unlock or an included paid-plan unlock is applied. Source push and repository export follow that same rule. The $4.99 one-time unlock remains attached to the project; Plus, Pro, and Ultra provide their configured unlock allowances. Review the entitlement state before attempting a source handoff rather than treating repository authorization as proof that export is allowed.

After authorization, review the repository destination and visibility. A public repository makes its contents public; a private one still grants access to its authorized collaborators and services. Check assets, font licenses, deployment instructions, and hosted dependencies before publishing. A repository export can contain actual Git history objects without storing your remote credentials. Keep those credentials out of the archive and avoid committing an environment file merely because a local build depends on it.

Before starting a new source change, determine where the latest accepted work lives. If someone edited the repository, pull and review that change before adding another conflicting revision in the builder. If the builder contains the latest work, inspect the intended push destination and the changes being published. Avoid treating synchronization as an invisible continuous process. Explicit operations make it easier to understand what happened when two people or tools work on the same files.

Test a small round trip before relying on the workflow for a major handoff. Make a controlled change, confirm it appears in the expected repository content, then pull an authorized repository change and verify the preview. Preserve a known-good version first. Do not assume that changing the repository triggers external hosting; that depends on your configured deployment pipeline. Likewise, a frontend sync does not copy private visitor records, leads, receipts, or managed-service credentials into Git.

A conflict means the system cannot safely combine competing changes automatically. It commonly occurs when two changes touch the same content or one side deletes something the other edits. GitHub's documentation explains why a merge needs a deliberate resolution. Do not interpret a conflict as permission to overwrite the repository wholesale. First identify the shared baseline, what changed in the builder, and what changed remotely. Then decide which final behavior should exist.

Resolve related files together. A changed button may depend on a handler, style rule, and destination route; keeping only the visual part can create a broken control. After resolving, test the affected journey and nearby features. If the changes are large or the intended result is unclear, preserve both versions and involve the person responsible for the code. A forced replacement can remove work while appearing to simplify the sync, so use the conflict-aware workflow and review the outcome.

Use saved-version restoration when a completed revision moved in the wrong direction and you want an earlier website result. Confirm the version's content, assets, and behavior before continuing. Restoration changes the displayed version; pending draft requirements can still be a separate state. If you want the restored version's applied settings to become the basis of future work, use the supported explicit workflow and review what is being copied rather than assuming every draft field rewinds automatically.

Restoring frontend content does not necessarily roll back hosted records, payments, or an external deployment. A reading journal's saved books remain service data, not simply part of a page snapshot. If the restored UI expects a different data shape, test it carefully. Keep the release record updated and decide whether the repository or external host also needs a reviewed rollback. Recovery is complete when the visitor journey works again, not merely when the older homepage reappears.

An interrupted build can retain completed private files and a recoverable candidate. Uvilno distinguishes these drafts from the last verified version. A renderable draft may be explored in the isolated owner preview while verification is unfinished, including retained candidates from failed or cancelled runs within the supported retention period. Opening that draft does not unlock source, promote it to a completed version, or prove its interactions are safe to publish.

Retrying an unchanged eligible run can reuse retained work after the owner, project, base version, requirements, and assets are checked. If you materially change the brief or base version, do not assume the same recovery applies. Inspect the status and follow the supported retry path. Once the whole candidate passes and saves, test its main journeys before export or sync. Keep failures described accurately: recovered files, a usable draft, a verified version, and a deployed release are four different milestones.