3 ms·

Both reasons. Mostly it's because it seems people are using Git to deploy without a good reason. At least I haven't heard of an advantage enjoyed by those usin

by tux1968 13y ago

Both reasons. Mostly it's because it seems people are using Git to deploy without a good reason. At least I haven't heard of an advantage enjoyed by those using Git for deployment. There are some obvious disadvantages, so what is the compensation? It seems the only reason is that it's easy to type "git push". But of course any deployment method can be wrapped in an equally easy script command. Okay, I have to admit to knowing of one advantage, and that is that only the delta of your changes will be transmitted over the wire, rather than a complete checkout. It's just that in practice the savings aren't usually enough to warrant the potential downsides. For my money i'd prefer rsync or any number of other solutions.

RussianCow 13y ago
What are the potential downsides? I've been deploying with Git for over a year and am interested in learning why it's not a good idea.
- Marc_Paradise 13y ago
  Security. Are you 100% sure that there is nothing you are exposing via your git repo that you want to keep away from the person who manages to hack your server or discover some means to reach the repo externally? Getting hacked is not inevitable, but if you treat your systems as if it were you'll be a lot safer if it does ever occur.
  - zzzeek 13y ago
    If you push via git or via rsync, you're typically going over SSH in both cases. As far as the .git directory, my post-receive hook also does a "cp -R" of the files to the actual web-served directory (there's a build step in between anyway), so there's no .git exposed. As far as security, as long as one knows to handle the .git directory, there's no difference.
  - kyrias 13y ago
    If there's anything in your repo history that you don't want a hacker to find you can just remove it and force push.
    - Peaker 13y ago
      "Just remove it" is hard, because: * It may be hidden in some old commit (e.g: some password) * You'd need to rewrite all history from that point * Force push doesn't necessarily clean the data from the remote
      - michaelmior 13y ago
        FWIW, the "hidden in some old commit" problem is easily solvable with git-filter-branch. But the second two points are certainly valid :)
      - eru 13y ago
        Change the old passwords?
        Peaker 13y ago
        I think the main problem is unknown exposure: Do you audit all old commits to find any sensitive data?
        eru 13y ago
        Shouldn't you audit all commits in any case?
        bradleyland 13y ago
        So, you have two choices: 1) You can go through the trouble of identifying and resolving all the edge cases that you encounter when using Git as a deployment tool. Keeping in mind that one of those may result in an embarrassing security disclosure. Woops. 2) You can use a deployment tool that was developed for that purpose, has existed for years, and has had many sets of eyes on it; many of which are inevitably more experienced than you. And you still may end up with an embarrassing security disclosure, but the chances are better that you'll hear about it through responsible disclosure channels first, rather than waking up at 3 AM to the voice of your boss/client asking why the site is redirecting users to buy Viagra at a discount. A bonus third choice: 3) You look at existing deployment tools and ask yourself "I wonder why they do that?" Then, maybe ask around a bit. Once you've got a good idea of all idiosyncrasies involved with deploying software, then you embark upon building your own tool. I think you'll find that simply `git pull`ing from your httpd document root and `rm -R`ing the .git/ directory won't be your final solution.
mnutt 13y ago
The way we have it set up in capistrano, git is used as the distribution mechanism. It offers a lot of flexibility in that you can deploy a tag or a revision hash or whatever without having to worry about consistencies between users' machines or having to deal with an external packaging machine. Once the repo has been fetched, we just check out the right tag/revision and do a local copy from the git repo into the app directory. At this step you can exclude .git if you want. This process has an advantage over direct git checkout in that if you (heaven forbid) ssh onto the server and directly modify anything, you won't end up with conflicts.

by tux1968 13y ago

RussianCow 13y ago

What are the potential downsides? I've been deploying with Git for over a year and am interested in learning why it's not a good idea.

Marc_Paradise 13y ago
Security. Are you 100% sure that there is nothing you are exposing via your git repo that you want to keep away from the person who manages to hack your server or discover some means to reach the repo externally? Getting hacked is not inevitable, but if you treat your systems as if it were you'll be a lot safer if it does ever occur.
- zzzeek 13y ago
  If you push via git or via rsync, you're typically going over SSH in both cases. As far as the .git directory, my post-receive hook also does a "cp -R" of the files to the actual web-served directory (there's a build step in between anyway), so there's no .git exposed. As far as security, as long as one knows to handle the .git directory, there's no difference.
- kyrias 13y ago
  If there's anything in your repo history that you don't want a hacker to find you can just remove it and force push.
  - Peaker 13y ago
    "Just remove it" is hard, because: * It may be hidden in some old commit (e.g: some password) * You'd need to rewrite all history from that point * Force push doesn't necessarily clean the data from the remote
    - michaelmior 13y ago
      FWIW, the "hidden in some old commit" problem is easily solvable with git-filter-branch. But the second two points are certainly valid :)
    - eru 13y ago
      Change the old passwords?
      - Peaker 13y ago
        I think the main problem is unknown exposure: Do you audit all old commits to find any sensitive data?
        eru 13y ago
        Shouldn't you audit all commits in any case?
        bradleyland 13y ago
        So, you have two choices: 1) You can go through the trouble of identifying and resolving all the edge cases that you encounter when using Git as a deployment tool. Keeping in mind that one of those may result in an embarrassing security disclosure. Woops. 2) You can use a deployment tool that was developed for that purpose, has existed for years, and has had many sets of eyes on it; many of which are inevitably more experienced than you. And you still may end up with an embarrassing security disclosure, but the chances are better that you'll hear about it through responsible disclosure channels first, rather than waking up at 3 AM to the voice of your boss/client asking why the site is redirecting users to buy Viagra at a discount. A bonus third choice: 3) You look at existing deployment tools and ask yourself "I wonder why they do that?" Then, maybe ask around a bit. Once you've got a good idea of all idiosyncrasies involved with deploying software, then you embark upon building your own tool. I think you'll find that simply `git pull`ing from your httpd document root and `rm -R`ing the .git/ directory won't be your final solution.

mnutt 13y ago

The way we have it set up in capistrano, git is used as the distribution mechanism. It offers a lot of flexibility in that you can deploy a tag or a revision hash or whatever without having to worry about consistencies between users' machines or having to deal with an external packaging machine. Once the repo has been fetched, we just check out the right tag/revision and do a local copy from the git repo into the app directory. At this step you can exclude .git if you want. This process has an advantage over direct git checkout in that if you (heaven forbid) ssh onto the server and directly modify anything, you won't end up with conflicts.