This article explains how to set up Git-based version control for your Web60 website to track code changes and manage updates.
Before You Start
Git is a system that tracks changes to your website files. Think of it like a detailed history of every change you make. This is useful when you want to see what changed, who changed it, or undo changes that caused problems.
You'll need basic command line knowledge for this setup. If you're not comfortable with technical commands, consider asking a developer for help.
Step 1: Access Your Website Files
Log into your Web60 portal and navigate to the File Manager section. Your WordPress files are located in the public_html folder. This is where all your website content lives.
Download your website files to your local computer if you plan to work locally, or work directly on the server using the built-in terminal access.
Step 2: Initialize Git Repository
In your website's root directory (public_html), run this command:
git init
This creates a hidden .git folder that tracks all changes to your files. Your website now has version control capabilities.
Step 3: Create Your First Commit
Add all existing files to Git tracking:
git add .
git commit -m "Initial website setup"
This creates a snapshot of your current website. The message "Initial website setup" describes what this version contains.
Step 4: Set Up .gitignore File
Create a .gitignore file in your root directory. This tells Git which files to ignore. Add these common WordPress exclusions:
wp-config.php
wp-content/uploads/
*.log
.htaccess
This prevents sensitive files and large media uploads from being tracked.
Step 5: Connect to Remote Repository
If you want to store your code on GitHub, GitLab, or similar services, create a repository there and connect it:
git remote add origin [your-repository-url]
git push -u origin main
Replace [your-repository-url] with the actual URL from your Git hosting service.
Step 6: Create Regular Snapshots
After making changes to your website, create new snapshots:
git add .
git commit -m "Updated contact form styling"
Use clear, descriptive messages that explain what you changed.
Best Practices
Make commits frequently, especially before major changes. This gives you more restore points if something goes wrong.
Before making changes, consider creating pre-update snapshots through the Web60 backup system as an additional safety measure.
Test changes on a staging site first. If you need help with this, check our guide on setting up WordPress staging sites.
If you're still stuck with Git setup or need help with version control best practices, contact Web60 support through your portal. Include details about what step you're having trouble with.
FAQ
Q: Will Git slow down my website?
A: No. Git only tracks files and doesn't affect your live website performance. The .git folder is hidden and not served to visitors.
Q: Can I use Git with WordPress plugins and themes?
A: Yes, but be careful with automatic updates. Git tracks manual changes, but WordPress automatic updates might create conflicts that need manual resolution.
Q: What's the difference between Git and Web60 backups?
A: Git tracks code changes with detailed history and lets you see exactly what changed. Web60 backups create complete website snapshots for disaster recovery. Use both for complete protection.
Q: Can I revert to an older version using Git?
A: Yes, use git checkout [commit-hash] to view old versions, or git revert [commit-hash] to undo specific changes. Always backup before reverting.
Q: Do I need to commit wp-content/uploads folder?
A: No, exclude it in .gitignore. Media files are large and change frequently. Your regular Web60 backups handle media files better than Git.
Q: Can multiple people work on the same website using Git?
A: Yes, but it requires coordination. Each person needs Git access and must pull changes before pushing their own. Consider using branches for different features.
Q: What happens if I delete the .git folder?
A: You lose all version history but your website continues working normally. You can run git init again to start fresh version control.
Last updated: 1 March 2026