I would have one person who is responsible for deploying to different servers, especially for staging and production. Thus, when creating the release branch, this branch will be deployed to the intermediate server. When the release department is complete, you deploy the main branch to the production server.
You can clone the repo for production and production, just make sure that the .git directory has the correct protection (.htaccess is your friend :)) so that no developers can access this directory.
I would use git pull on a production server. I also read about rsync and hooks, but just git works fine for me.
Now sometimes, when I work for a client that does not allow git on the server, and I use ftp. There is a Pyhton program on github called git-ftp , which I adapted a bit to host git-flow. I did not put this version on github, maybe it should.
According to the first comment
The person performing the production and production releases will perform the following steps on his local machine:
git flow release start -F 1.0
do some work like update version number Post it to github
git flow release publish 1.0
On the staging server:
git pull origin release/1.0
After the end of the period of setting up the local machine
git flow release finish 1.0
On a production server
git pull origin master
source share