Deploy PHP with a git push
Reviewed
Markdown ↓📤
Push code, go live.
Deploy a PHP app with git push — this tutorial goes from a local project folder to a live website. Commit code, push it, and the deployment runs on its own.
About git push deployment
Git push deployment means that the same git push that sends commits to a Git repo also updates the live PHP website. Git is not only a version control system here, but also part of deployment. New to Git? The Git intro covers what Git is, how to install it, and where to learn the basics.
Git is efficient. It negotiates with the remote which commits it already has and transfers only the missing objects, compressed into a single packfile. Pushing a one-line fix to a large codebase sends a few kilobytes only. Since every push points to a commit, the deployed state is versioned and reproducible.
Git itself is open source and vendor-neutral. A Git remote can live anywhere — GitHub, GitLab, Bitbucket, or a self-hosted bare repo — the protocol stays the same. fortrabbit integrates with GitHub; see Git providers on how to combine it with others with custom pipelines.
From git push to live website
There is no special fortrabbit Git remote to configure and push to — pushes go to GitHub as usual. The fortrabbit GitHub App listens for new commits on the branch that is connected to an environment. Each push triggers a deployment pipeline:
- The GitHub App gets notified about the push and pulls the latest code into a build container.
- The build commands run, for example
composer install. - The build result is synced into the web space of the environment with rsync — which again transfers only the files that changed.
The deployment intro covers the pipeline in more detail.
Get ready
- Have Git installed on the local machine.
- Have a GitHub account.
- Have a PHP project — plain PHP is fine, frameworks and CMSs work too.
- Have a fortrabbit account, the free trial is enough.
Step 1: Put the project in a Git repo
Skip ahead if the project is already under version control. Otherwise, open a terminal in the project folder:
git init
git add .
git commit -m "Initial commit"
Before the first commit, add a .gitignore file so generated files and secrets stay out of the repo:
/vendor/
.env
The vendor folder does not belong in Git — dependencies get installed during deployment. See the Composer article for the reasoning.
Step 2: Push it to GitHub
Create a new repository on GitHub, then connect it to the local repo and push:
git remote add origin git@github.com:{{user}}/{{repo}}.git
git push -u origin main
This also works the other way around: when creating an app on fortrabbit, the GitHub App can create a fresh empty repo.
Step 3: Connect the repo to fortrabbit
- Sign up — or log in — with GitHub.
- This installs the fortrabbit GitHub App on GitHub.
- On fortrabbit, create an app.
- Pick the repository and branch:
- The Git repo maps to the app.
- The Git branch maps to the environment —
mainfor production, other branches for staging.
During setup, fortrabbit inspects the repo and preconfigures the deployment: when it finds a composer.json, the build commands will include composer install.
Step 4: Deploy with a git push
That was the one-time setup. From now on, deployment is part of the normal Git routine:
git commit -am "Update homepage"
git push
Push to deploy is the default deployment trigger: every push to the connected branch starts a deployment automatically. Follow the progress in the deployment logs in the dashboard, then open the app URL in the browser to see the change live.
What gets deployed — and what not
Git only moves code: PHP classes, templates, themes, CSS, JS. Uploads, the database, and other runtime data are not part of the deployment and stay untouched on the environment. Git is also a one-way street here — changes on the web space can not be pulled back into the repo. The deployment intro explains this separation of code and content.
Where to go next
- Follow a framework-specific install guide for Laravel, Craft CMS, Kirby, Statamic, or WordPress.
- Run database migrations or clear caches after each deployment with post-deploy commands.
- Set up a staging environment on a second branch.
- Something not working? See deployment troubleshooting or .