GitZilla Documentation

Before you start

You need Windows PowerShell, Git for Windows, and WinSCP (the Windows download includes it when bundled). Work from inside the Git repository you want to deploy. The desktop app opens when you run GitZilla with no command.

Install and get help

# Run the downloaded installer, then open a new PowerShell window.
gitzilla help
gitzilla ui

Connect an existing repository

Use connect from the repository root. GitZilla attempts to match a saved deployment target using the repository path, folder name, project key, or saved display name. If it finds one clear match, it saves that connection and installs the post-commit hook.

cd C:\Projects\my-site
gitzilla connect

# Choose a known saved target explicitly when matching is ambiguous.
gitzilla connect -FromProject "production-site"

Create a new deployment target

Use init for a new target. Passwords supplied here are stored in a per-user Windows environment variable; do not put real passwords in source control.

gitzilla init `
  -Project "my-site-production" `
  -FtpHost "ftp.example.com" `
  -Username "deploy-user" `
  -Password "your-password" `
  -RemotePath "/public_html"

# Or reuse an imported/saved target.
gitzilla init -Project "my-site-production" -FromProject "existing-production"

# Other lookup options
gitzilla init -Project "my-site-production" -FromHost "ftp.example.com"
gitzilla init -Project "my-site-production" -FromDisplayName "My Production Site"

Deploy commands

Run these from the connected repository. `staged` is the default. Start with a dry run whenever you are uncertain.

# Current staged files (default)
gitzilla deploy
gitzilla deploy staged
gitzilla deploy -Mode staged

# Preview without transferring anything
gitzilla deploy -Mode staged -DryRun
gitzilla deploy -DryRun~5

# Files from the latest commit
gitzilla deploy head
gitzilla deploy -Mode head

# A specific commit range
gitzilla deploy -Mode range -FromRef origin/main -ToRef HEAD

# Redeploy the last 1 to 10 commits
gitzilla deploy past2

# Stage every tracked, untracked, and deleted change, then deploy
gitzilla deploy all

Deploy, commit, and push

Adding `-m` is an all-in-one workflow: GitZilla commits the staged work, deploys that commit, then pushes it only after every deployment target succeeds. This creates a stable per-target recovery point if a server fails.

gitzilla deploy -m "Publish homepage update"
gitzilla deploy all -m "Publish homepage update"
gitzilla deploy staged -m "Publish homepage update"
gitzilla deploy head -m "Publish homepage update"

Hooks and desktop UI

The recommended post-commit hook deploys the files from a successful commit. The UI is useful when choosing repositories and saved targets.

gitzilla install-hook
gitzilla install-hook -Project my-site-production
gitzilla ui
# No command also opens the UI
gitzilla

Credentials and safe deployment

Your live configuration is local to your computer and is never included in the public download. Prefer `passwordEnv` in the local GitZilla configuration or a saved WinSCP session. Remote deletes are disabled by default. Only enable them after confirming a deleted Git file must also be removed from production.

# Explicitly allow remote deletion for this one deployment.
gitzilla deploy -Mode staged -AllowRemoteDeletes

# Import a FileZilla export locally (never upload the export itself).
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "C:\Path\To\GitZilla\import-filezilla.ps1" -FileZillaXmlPath "C:\Downloads\FileZilla.xml"

# Move an imported plaintext password into a Windows user environment variable.
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "C:\Path\To\GitZilla\protect-project-password.ps1" -Project "my-site-production"

Agent / LLM hand-off

Give an agent this public documentation URL and ask it to follow the dry-run-first workflow. The agent must work only with the user’s local Git repository and local GitZilla configuration. It must never ask for, print, commit, upload, or place credentials in a repository.