5 ms·

Why would you ever want to put a git repo on a production server in the first place? Unless you're using the production server for development (gasp) it sounds

Why would you ever want to put a git repo on a production server in the first place? Unless you're using the production server for development (gasp) it sounds like a waste of space and (as pointed out here) a major security vulnerability.

nooyurrsdey 8y ago
This question basically restate the problem. It's not that people want to do that, they just don't know better
ktpsns 8y ago
An answer for Subversion would be: Because "svn update" (http://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.update.html http://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.update.html) runs faster then "svn export" (http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.export.html http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.export.html). For git there is not even an "export" option anymore (cf. https://stackoverflow.com/questions/160608/do-a-git-export-like-svn-export https://stackoverflow.com/questions/160608/do-a-git-export-l...), but nevertheless "git pull/push" is an easy way to keep the production server code synced. It is certainly not the best.
- wongarsu 8y ago
  >It is certainly not the best. What is the better alternative? Git checkout makes reverting to a previous version fast and convinient, and git's protocol seems more efficient than transmitting the files via scp or similar since most of the files are already there. I guess I could have a build server rsync the files over, but that seems like a lot of complexity for little gain.
  - icebraining 8y ago
    Git doesn't ensure the checkout process is atomic; it might leave you with an unfinished mess if it fails for some reason. Also, it means that everything you ever committed on the release branch will be available on a more exposed server.
  - _-david-_ 8y ago
    >What is the better alternative? This is a bit complicated to do by hand, but this is probably the best way. I would suggest using existing software to handle this though Create a file that just has "2" with no quotes in it. Create a directory called 1. Create a symlink that points to that directory. Have the webserver use the symlink instead of the actual code directory. When you want to update code lock the file that has the number in it. Read in the contents of the file. Replace the contents of the file with the next number. Unlock the file. Create a directory with whatever number you read in. Git clone in that new directory. Do whatever else you need to do (compilation or whatever). If all goes well then change a symlink to point to the new directory. If you need to revert then change the symlink to the old directory. You could also delete old directories as well to save some space.
- cpburns2009 8y ago
  Using git pull (or some equivalent) to update a production environment is fragile and just asking for trouble.
siruncledrew 8y ago
I've seen someone SCP a local git repo to an Amazon EC2 (obviously not best practice) for a manual deployment.
tzs 8y ago
You can go a long way toward avoiding the security issue by making good use of the GIT_DIR and GIT_WORK_TREE environment variables.

nooyurrsdey 8y ago

This question basically restate the problem. It's not that people want to do that, they just don't know better

ktpsns 8y ago

An answer for Subversion would be: Because "svn update" (http://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.update.html http://svnbook.red-bean.com/en/1.8/svn.ref.svn.c.update.html) runs faster then "svn export" (http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.export.html http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.export.html). For git there is not even an "export" option anymore (cf. https://stackoverflow.com/questions/160608/do-a-git-export-like-svn-export https://stackoverflow.com/questions/160608/do-a-git-export-l...), but nevertheless "git pull/push" is an easy way to keep the production server code synced. It is certainly not the best.

wongarsu 8y ago
>It is certainly not the best. What is the better alternative? Git checkout makes reverting to a previous version fast and convinient, and git's protocol seems more efficient than transmitting the files via scp or similar since most of the files are already there. I guess I could have a build server rsync the files over, but that seems like a lot of complexity for little gain.
- icebraining 8y ago
  Git doesn't ensure the checkout process is atomic; it might leave you with an unfinished mess if it fails for some reason. Also, it means that everything you ever committed on the release branch will be available on a more exposed server.
- _-david-_ 8y ago
  >What is the better alternative? This is a bit complicated to do by hand, but this is probably the best way. I would suggest using existing software to handle this though Create a file that just has "2" with no quotes in it. Create a directory called 1. Create a symlink that points to that directory. Have the webserver use the symlink instead of the actual code directory. When you want to update code lock the file that has the number in it. Read in the contents of the file. Replace the contents of the file with the next number. Unlock the file. Create a directory with whatever number you read in. Git clone in that new directory. Do whatever else you need to do (compilation or whatever). If all goes well then change a symlink to point to the new directory. If you need to revert then change the symlink to the old directory. You could also delete old directories as well to save some space.
cpburns2009 8y ago
Using git pull (or some equivalent) to update a production environment is fragile and just asking for trouble.

siruncledrew 8y ago

I've seen someone SCP a local git repo to an Amazon EC2 (obviously not best practice) for a manual deployment.

tzs 8y ago

You can go a long way toward avoiding the security issue by making good use of the GIT_DIR and GIT_WORK_TREE environment variables.