Git is a fantastic tool that allows developers to collaboratively work on a project whilst storing a complete version history of every change made that easily lets you revert back changes or roll-back complete phases of your development timeline.
If you're already using Git - great! If not, I strongly suggest you start using Git for your projects. Even if you're working single-handedly on a project, Git will really take the ease off your back of accidentally removing a file or updating some code that'll propogate through your application and introduce bugs.
One of the hardest things for developers is working out how to deploy their Git repository onto a remote server without having to spend too much time faffing. Coming up with a remote deploy mechanism is ideal when you're managing a lot of Git repositories that all need deploying on different environments.
There are two ways we're going to run over that'll aid you in setting up a remote deploy. You can either use an automatic deploy tool or setup a Git and use the hooks yourself.
Third-Party Automatic Deployment
There are a large amount of third-party apps online that'll handle your Git repository for you and take care of deploying it to your web server. Here's a list you can checkout, though they do offer a free version on each, you'll typically end up paying for a couple of repositories.
Codeship allows you to easily integrate with a Bitbucket or GitHub account, load in your repositories and then deploy them direct to your server through SSH or SFTP. The free plan allows you to have 1 concurrent build, 5 projects and 50 builds a month.
Deploy is similar to Codeship though their billing is on a per-project basis. Deploy allows you to hook up your repository to a remote Amazon S3, VPS through SFTP/SSH or using the bog standard FTP protocol.
CloudBees is different to Codeship and Deply as it provides a continuous integration. Rather than deploying in one large chunk, every commit or merge into a delegated specific branch will be deployed and integrated into an existing application
CircleCi is another continous integration method that allows you to seamlessly ensure your remote server is always up-to-speed with your Git repository. Pricing is charged on a per-container basis though allows you to setup unlimited private projects, parallelism, collaborators, builds and build time.
Manual Git Repository Deployment
On the server you want to deploy the Git repository on, you need to have Git installed and running, then create a new repository.
mkdir ~/www/application && cd ~/www/application git init
Now we need to setup the server's Git repository to handle the deployment:
git config core.worktree ~/www/application git config receive.denycurrentbranch ignore
The final step on the remote server is setting up a Git post-receive hook that'll hande the update.
vi .git/hooks/post-receive #!/bin/sh git checkout -f
Save the file and then call:
chmod +x .git/hooks/post-receive
Setting up a Remote Origin
On your local Git repository, you need to setup a new remote origin so that our repository can actually be deployed:
cd ~/www/application git remote add origin ssh://USER@YOUR_IP_DOMAIN/home/user/www/application
For the very first push to your server, you'll need to push to master and the origin:
git push origin master
Then every consequent update would be:
Now you'll be able to ensure your remote server is always up-to-speed with your local git. If you're using a Git application such as GitHub or Sourcetree, you can setup deployment on a specific branch so that mini-push updates aren't deployed straight away.