Deploying a website with Git gives developers a repeatable path from a local change to a running application. This guide explains how to organize the repository, configure SSH access, manage environment variables, separate staging from production, automate releases, inspect logs, and roll back safely across shared hosting, VPS hosting, and cloud hosting environments.
Overview
A reliable Git deployment workflow is more than copying files to a server. It defines what belongs in the repository, which branch can reach production, how secrets are supplied, which build commands run, and how a failed release is reversed. The exact implementation depends on the hosting control panel, operating system, deployment tool, and application stack, but the underlying process is consistent.
A practical workflow usually has four stages:
- Develop: Make and test changes in a local working copy.
- Review: Commit the change to a feature branch and check it before merging.
- Deploy: Build and release the approved branch to staging or production.
- Verify: Check the application, logs, assets, integrations, and rollback path.
For a static site, deployment may only require checking out a repository and publishing a generated directory. A framework application may also need dependency installation, asset compilation, database migrations, process restarts, and cache handling. Define those steps before connecting Git to a live domain.
On shared hosting, a hosting control panel may provide Git deployment, a repository hook, or a deployment script. On VPS or cloud hosting, you can use SSH, a bare Git repository, a CI/CD runner, or a platform integration. If your application is managed WordPress hosting, Git may be most appropriate for a custom theme, plugin, or separate build process rather than for the entire site.
What to track
Repository structure and tracked files
Keep application code, configuration examples, deployment scripts, and documentation in predictable locations. A simple structure might include src/ for source files, public/ or dist/ for generated output, scripts/ for repeatable commands, and a README that explains local setup and deployment.
Use .gitignore to exclude dependency directories, build output when it is generated during deployment, local environment files, logs, temporary uploads, and private keys. Commit a safe template such as .env.example, but never commit the real values from .env. Record the required variable names and expected formats in the documentation.
SSH keys and access boundaries
Create a deployment key specifically for the repository or deployment process rather than reusing a personal private key. The private key should remain outside the repository and should be readable only by the account that needs it. Add the public key to the appropriate Git provider or server account, and test access with a non-destructive command before attempting a release.
Use separate access for staging and production where practical. A deployment process should have only the permissions required to read the repository, write the application directory, run approved build commands, and restart the relevant service. Avoid using a broad administrative account for routine deployments.
Branches, builds, and environment variables
Choose a branch policy that is easy to enforce. For example, feature branches can merge into staging for testing, while only reviewed changes from main can reach production. The branch names are less important than making the promotion path clear.
Track the deployment branch, commit identifier, build command, dependency command, migration command, release directory, and restart command for each environment. Staging and production should not silently share values for database credentials, API keys, debug settings, or callback URLs. Supply these values through the host, CI/CD system, or server environment rather than through Git.
Logs, permissions, and release state
Know where web server, application, build, and process-manager logs are stored. A deployment is incomplete if the team cannot determine whether a failure occurred during checkout, dependency installation, the build, the service restart, or the first request.
Track file ownership and permissions after every deployment. The web-serving account may need read access to published files, while writable directories such as caches or uploads should be limited to the paths that require writing. Do not make the entire application directory universally writable as a shortcut.
Cadence and checkpoints
Review the workflow monthly or quarterly, even when deployments appear uneventful. The goal is to catch drift: an expired key, a changed build command, an untested rollback, growing logs, or a staging environment that no longer resembles production.
Before the first deployment
- Confirm the repository builds successfully from a clean checkout.
- Document the runtime version and dependency installation command.
- Confirm the domain, DNS records, SSL certificate, and application document root point to the intended environment.
- Create and test SSH access without exposing private keys.
- Define required environment variables and keep their values outside Git.
- Identify the log locations and the command used to restart the application.
- Write down a rollback procedure and test it on staging.
For every release
Start with a clean working tree and a reviewed commit. Record the commit identifier in the deployment log. Run tests and the production build using the same commands that the host or pipeline will use. Confirm that the deployment targets the intended branch and directory.
After publishing, test the home page, representative internal pages, forms or authentication, database-backed actions, static assets, redirects, and important third-party integrations. Check the application logs for new errors rather than relying only on whether the first page loads.
For the monthly or quarterly review
Check SSH keys and user access, dependency and runtime versions, disk usage, log rotation, backup availability, branch protection, environment variable documentation, and the last successful rollback test. Also review whether the current hosting environment still fits the workload. A small static site may remain comfortable on shared hosting, while increasing build time, memory use, or traffic may justify a VPS or cloud hosting arrangement.
How to interpret changes
A failed deployment does not always mean the application code is wrong. Separate the failure into stages. A checkout error often points to repository permissions or SSH configuration. A dependency error may indicate a runtime mismatch or an unavailable package. A build error usually belongs to the application or build configuration. A successful build followed by a broken site may indicate missing environment variables, incorrect file permissions, an invalid document root, a failed migration, or a service that did not restart.
Compare the current release with the last known-good commit. If the new release is faulty and the previous version is compatible with the current environment, roll back to that commit or release directory rather than editing production files manually. Manual edits make the server different from Git and make the next deployment harder to reason about.
For safer rollbacks, publish each release into its own directory and point a stable path, such as current, to the active release. A rollback can then switch the active path to the previous release, subject to application and database compatibility. If a database migration cannot be reversed, treat the migration as a separate risk and use a backward-compatible sequence where possible.
Watch for patterns rather than isolated messages. Repeated permission errors suggest an ownership problem. Increasing build duration may indicate dependency or resource growth. Errors that appear only after DNS changes may involve the wrong document root, cached records, or an environment-specific hostname. Keep a short deployment record containing the date, commit, operator or pipeline, result, failure stage, and corrective action.
When to revisit
Revisit this Git deployment workflow at least monthly or quarterly, and immediately after a hosting migration, domain change, framework upgrade, repository restructure, security incident, or change from manual deployment to CI/CD. Also review it when the team adds a new environment, changes the production branch, introduces a database migration, or replaces the hosting control panel.
Use the following short checklist during each review:
- Can a new developer reproduce the application from a clean checkout?
- Can the deployment process identify the exact commit running in production?
- Are secrets absent from Git and available in every required environment?
- Can the team find logs quickly and distinguish build failures from runtime failures?
- Has a rollback been tested recently on a safe environment?
- Do file permissions, SSH access, backups, and DNS settings still match the documented design?
Update the README, deployment script, CI/CD configuration, and hosting notes whenever one of these answers changes. A Git workflow remains dependable when it is treated as an operational system, not a one-time setup task. For related infrastructure work, review a shared hosting versus VPS comparison, the DNS records guide, or the website migration checklist before changing the hosting environment.
