Git Deployment Guide: Professional Web Hosting Deployment

Learn Git deployment for professional web hosting management

If you're a professional web developer, you've probably used FTP or SFTP to upload files to your server. However, this method has significant drawbacks: it's time-consuming, error-prone, and lacks proper version control. Git deployment is the professional industry standard for managing web application deployments. In this comprehensive guide, we'll show you how to deploy websites using Git on Thai VPS and hosting providers, covering Git workflows, GitHub Actions CI/CD, WordPress deployments, .gitignore best practices, and rollback procedures.

What is Git and Why Use It for Web Deployment?

Git is a distributed version control system (VCS) that helps developers track code changes, commit modifications, and revert to previous versions when necessary. Created by Linus Torvalds for managing the complex Linux kernel project, Git has become the industry standard for version control and deployment automation.

Git enables web deployment because it provides push capabilities to remote repositories. When you push code to your server's Git repository, Git hooks can automatically trigger scripts that pull the updated code and deploy it to your web root. This approach is faster, more secure, and much easier to manage than traditional FTP uploads.

Beyond speed, Git deployment offers numerous advantages: complete change tracking, easy team collaboration, branch management for feature development, instant rollback capabilities, integration with CI/CD pipelines, superior security, and detailed deployment history. These features make Git deployment the standard for professional web development teams and DevOps practices.

Git vs FTP: Which Deployment Method is Better?

Before diving into Git deployment setup, let's compare Git with FTP to understand why Git is superior for modern web hosting management. This comparison will help you appreciate the benefits you'll gain by switching to Git-based deployments.

FTP (File Transfer Protocol) is the traditional file transfer method. You open an FTP client, connect to your server, and manually upload changed files. While straightforward, this approach has significant drawbacks. You must manually track which files changed, uploading the correct versions is error-prone, managing team deployments is complicated, and reverting failed deployments is difficult and time-consuming.

FTP Disadvantages: Time-consuming uploads of many files, no change tracking transparency, high risk of uploading wrong versions, difficult rollback procedures, unsuitable for team development due to conflict management issues, manual tracking of files to upload.

Git Deployment uses version control for code management. You commit code locally, push to a remote repository (GitHub, GitLab, or your server), and the server automatically pulls updated code via Git hooks. This streamlined process is fundamentally superior to FTP for professional development.

Git Deployment Advantages: Fast and simple deployment, complete change tracking, instant rollback capabilities, excellent for team collaboration, enables CI/CD automation, superior security practices, enables feature branch development and testing before merge.

In summary, Git deployment surpasses FTP in virtually every dimension, particularly for complex projects or team-based development. The learning curve is minimal compared to the efficiency gains achieved.

Setting Up a Git Repository on Your VPS

The first step in Git deployment is creating a repository on your VPS. Assuming you've rented a VPS from AsiaGB.com or similar hosting with SSH access, you'll begin by connecting via SSH.

ssh user@your-vps-ip

After connecting, create a directory for your repositories, typically under /var/www/ or your home directory. We'll create a dedicated repo directory for bare repositories.

mkdir -p /var/www/repo/mysite.git
cd /var/www/repo/mysite.git

Initialize a bare Git repository that will receive pushes from your local machine:

git init --bare

A bare repository contains no working directory and exists purely to receive pushes. This is the standard setup for server-side repositories. Next, create a directory for your actual website files:

mkdir -p /var/www/mysite

Now you need to configure a Git hook to automatically pull code to your web root when you push to the server. We'll cover this in detail in the Git Hooks section. This configuration completes the basic server-side setup for receiving deployments.

Deploying with Git Push Workflow

With your server repository configured, we can now discuss the standard Git push workflow for deploying websites. This is the daily workflow you'll use for managing deployments efficiently.

Start by cloning your GitHub repository to your local machine (if not already done):

git clone https://github.com/yourusername/mysite.git
cd mysite

After modifying files, stage your changes using the git add command:

git add .
git status

The git status command shows exactly which files are staged for commit. Now commit your changes with a descriptive message:

git commit -m "Fix homepage layout and add new features"

Push your changes to GitHub:

git push origin main

To deploy to your production server, add it as a remote and push there as well:

git remote add production user@your-vps-ip:/var/www/repo/mysite.git
git push production main

The git remote add production command creates a named remote pointing to your server's repository, and git push production main sends your code to the server, triggering the post-receive hook that automatically updates your website.

GitHub Actions for Automated Deployment

To fully automate your deployment process, GitHub Actions provides continuous integration and continuous deployment (CI/CD) capabilities. This eliminates manual push commands and ensures consistent deployments triggered by repository events.

Create a GitHub Actions workflow file at .github/workflows/deploy.yml:

name: Deploy to Production

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3

    - name: Deploy via SSH
      uses: appleboy/ssh-action@master
      with:
        host: ${{ secrets.VPS_HOST }}
        username: ${{ secrets.VPS_USER }}
        key: ${{ secrets.VPS_KEY }}
        script: |
          cd /var/www/repo/mysite.git
          git remote set-url origin https://github.com/yourusername/mysite.git
          git fetch origin main
          git reset --hard origin/main
          cd /var/www/mysite
          npm install
          npm run build

This workflow automatically deploys to your VPS when you push to the main branch. GitHub Actions connects via SSH, pulls the latest code, and runs your build scripts. The advantage is that all deployment logic is version-controlled and reproducible, eliminating manual deployment steps and reducing human error.

Deploying WordPress with Git

WordPress deployments require special handling because of dynamically generated content. The wp-content/uploads directory stores user-uploaded images and files, which can become very large and should never be included in Git commits, as this would bloat your repository and cause deployment issues.

Create a .gitignore file to exclude uploads and other dynamic content:

# WordPress
/wp-config.php
/wp-content/plugins/hello.php
wp-content/uploads/
.env
node_modules/
*.log

With this configuration, uploaded files remain on your server during deployments without being affected by Git operations. After deploying WordPress, ensure proper file permissions using SSH:

cd /var/www/mysite
sudo chown -R www-data:www-data .
sudo chmod -R 755 .
sudo chmod -R 644 wp-content/
sudo chmod 755 wp-content/uploads/
sudo chmod 755 wp-content/plugins/
sudo chmod 755 wp-content/themes/

These permissions allow your web server to manage WordPress files while protecting system security. This setup enables seamless WordPress development with Git while preserving user-uploaded content.

.gitignore: Files and Folders to Exclude

The .gitignore file tells Git which files and folders to exclude from version control. This is crucial because certain files should never be committed, such as configuration files containing passwords, log files, temporary build artifacts, and environment-specific settings.

A comprehensive .gitignore example:

# Configuration files
.env
.env.local
.env.*.local
config.php
wp-config.php

# Dependencies
node_modules/
vendor/
composer.lock

# Build output
dist/
build/
*.min.js
*.min.css

# Logs
logs/
*.log
npm-debug.log*

# OS files
.DS_Store
Thumbs.db
.vscode/
.idea/

# Temporary files
tmp/
temp/
*.tmp
*.swp
*.swo

# WordPress
wp-content/uploads/
wp-content/backup-*/
wp-content/upgrade/

Place .gitignore in your repository root and commit it so team members apply the same rules. This prevents accidental commits of sensitive files and keeps your repository clean. Good gitignore practices are fundamental to professional Git workflow management.

Rollback Procedures After Failed Deployments

The worst scenario for developers is deploying code that breaks your website. Git provides multiple safe methods to quickly recover from failed deployments, ensuring your site can be restored to working order in minutes.

The safest rollback method uses git revert, which creates a new commit that undoes changes from a specific commit while preserving complete history:

git log --oneline
git revert HEAD~1

The git log --oneline shows your commit history, and git revert HEAD~1 creates a new commit that reverts the previous commit's changes. This maintains complete history for auditing purposes.

Alternatively, git reset moves HEAD to a specific commit, but it permanently removes commits that come after it. Use this carefully:

git reset --hard HEAD~1

The --hard flag resets both commits and working directory to match the specified commit. This is powerful but dangerous if used incorrectly.

For reverting specific files only:

git checkout HEAD~1 -- path/to/file.php

After any rollback method, commit the changes and push to your server:

git commit -m "Revert changes to fix the issue"
git push production main

Git Hooks: Automated Deployment with post-receive

Git hooks are scripts that automatically execute when specific Git events occur, such as pre-commit, post-commit, or post-receive events. The post-receive hook is perfect for automatic deployment, running after your server receives a push.

Connect to your server and create the hook file:

ssh user@your-vps-ip
cd /var/www/repo/mysite.git
nano hooks/post-receive

Add this deployment script:

#!/bin/bash
WORKTREE=/var/www/mysite

while read oldrev newrev ref
do
  if [[ $ref = refs/heads/main ]];
  then
    echo "Deploying main branch to production..."
    git --work-tree=$WORKTREE --git-dir=/var/www/repo/mysite.git checkout -f
    echo "Deployment completed."
  fi
done

Make the hook executable:

chmod +x hooks/post-receive

Now whenever you push to the main branch, this hook automatically checks out your code to the web directory, making deployment instant and automatic. This setup provides seamless deployments with zero manual intervention after the push command completes.