Git: how to make remote directory update when pushed to?

Question

I want to use git to manage some data on a remote server, so I set up a non-bare repository there. I can push to it without problems, and the repository its

Answer 1

Use a post-update hook:

hooks

There you can execute whatever you want on each update.

Answer 2

This, happily, is now supported directly in git itself! You can find the details in this answer, which I have just upvoted:

https://stackoverflow.com/a/38363683/85360

It recommends configuring the remote with

git config receive.denyCurrentBranch updateInstead

so that pushes result in an updated working copy!

Answer 3

Git Version 1.9.1
Ubuntu Server 14.04 LTS
LAMP Server

I set my LAMP server to update my working directory of my Git repo whenever one of my web developers pushes a change to the server. I noticed that the log would note the new commits, but would not update the working directory. Instead of doing this manually (git checkout -f) for every update, this can be set automatically to do so after a push has been received.

1. In your ".git" directory, go into the "hooks" folder.

2. Create a file named "post-receive" within the "hooks" folder with this content:

   #!/bin/sh

   # Update working directory after receiving a push from remote clients.
   # This should be directed at the git working directory.
   
   GIT_WORK_TREE=/var/www/dev_site git checkout -f

3. Enable permissions to execute the file by typing "chmod +x post-receive" in the "hooks" folder.

It will now update the working directory when commits are pushed to the Git repo. My site now shows the changes when I visit it in a browser.

My working directory is /var/www/dev_site

Answer 4

You shouldn't do this. It's recommended to have bare repositories. In other words, no files checked out, just the .git directory itself. You can then checkout the repository to some other location on your server -- say, your web root. This way, you get:

• git best practice. According to the Git docs, you can get "unexpected results" if you don't follow it. Anyone who's done a good bit of programming knows that "unexpected results" is code for "will probably eat your children and should be avoided at all costs."

• better security, if you're planning to have the checked out files on the server accessible from a webserver.

• Local modifications on your checked-out code, and the ability to make quick changes on the live checked out code. You could attempt to do this directly on the repository, but it would be messy and more prone to error.

• The ability to update your server repository independently of updating your live service code. This is pretty crucial, if you're working remotely and need to send something to the server and then do further work before it will be ready for your live service, or if you have changes in your live service code (say, different configuration settings) and need to merge those changes with the changes in the repo, but can't do it just now.

I'd recommend the following steps:

• Follow the git docs on setting up a bare repository
• Check out code from your repo to your live service target dir
• Setup a git hook (post-commit should be the right one IIRC) to update your live service when the repository is updated. It should probably cd to the live service dir, and do a git pull --rebase, and maybe set some file permissions.
• Just push your code to the repo from your dev box from now on.