I tend to use Git for deploying production code to the web server. That usually means that somewhere a master Git repository is hosted somewhere accessible over
ssh, and the production server serves that cloned repository, while restricting access to
.gitignore. When I need to update it, I simply pull to the server's repository from the master repository. This has several advantages:
- If anything ever goes wrong, it's extremely easy to rollback to an earlier revision - as simple as checking it out.
- If any of the source code files are modified, checking it as easy as
git status, and if the server's repository has been modified, it will be come obvious the next time I try to pull.
- It means there exists one more copy of the source code, in case bad stuff happens.
- Updating and rolling back is easy and very fast.
This might have a few problems though:
If for whatever reason web server decides it should serve
.git/directory, all the source code there was and is becomes readable for everyone. Historically, there were some (large) companies who made that mistake. I'm using
.htaccessfile to restrict access, so I don't think there's any danger at the moment. Perhaps an integration test making sure nobody can read the
.git/folder is in order?
Everyone who accidentally gains read access to the folder also gains access to every past revision of the source code that used to exist. But it shouldn't be much worse than having access to the present version. After all, those revisions are obsolete by definition.
All that said, I believe that using Git for deploying code to production is reasonably safe, and a whole lot easier than
ftp, or just copying it over. What do you think?