Prepare the repository and destination
Use a public repository available through an HTTPS URL and keep the production-ready website in a named branch. Attach the intended domain first, wait until it is ready and choose its dedicated document root. The destination must not contain an unrelated application or files you still need; take a recoverable copy before connecting an existing directory.
Connect the Git website
Associate the prepared document root with the complete public HTTPS repository URL and exact branch name. Confirm that the destination and branch are correct before submitting. Private repository credentials and passwords must not be embedded in the URL.
Deploy and verify a release
A deployment can preserve the existing destination or reset it before copying the selected branch. A reset can replace files in that document root, so use it only when the repository is the complete source of truth. Wait for the deployment to finish, then test the public HTTPS page, a representative asset and every important application route.
Change the deployed branch
Confirm that the target branch exists and contains a complete deployable state before promoting it. Changing the configured branch and deploying it are separate steps; verify the public website after deployment rather than assuming that selecting another branch has already published it.
Recover or disconnect safely
Keep a known-good commit and a file or database recovery point before a risky deployment. If a release fails, do not submit another while the previous deployment is still running. Disconnecting the repository removes the deployment relationship but does not decide whether its files should be deleted. Inspect the document root before cleanup and restore the database separately when a release also changed application data.
Choose Git, Site Studio or an application
Use Git when your reviewed source repository already produces the complete website. Use Site Studio for a small business site edited directly in Workspace, or install WordPress, Joomla or PrestaShop when you need that application's administration experience. Keep each publishing method in its own document root so one tool cannot overwrite another site's files.
